Bug#594820: marked as done (clang: specify libstdc++ version of headers to use)

[Michael Wild]

On 05/27/2011 05:51 PM, Sylvestre Ledru wrote:
> reopen 594820
> thanks
> 
> Le vendredi 27 mai 2011 à 16:28 +0200, Michael Wild a écrit :
>> On 05/27/2011 02:03 AM, Debian Bug Tracking System wrote:
>>>
>>
>> Sorry, still doesn't work for me:
>>
>> echo "#include <fenv.h>" | clang -xc++ -E - | fgrep fenv.h
>> # 1 "/usr/include/c++/4.5/fenv.h" 1 3
>> # 31 "/usr/include/c++/4.5/fenv.h" 3
>> # 31 "/usr/include/c++/4.5/fenv.h" 3
>> # 34 "/usr/include/c++/4.5/fenv.h" 2 3
>> # 1 "/usr/include/c++/4.4/fenv.h" 1 3
>> # 36 "/usr/include/c++/4.5/fenv.h" 2 3
>>
>> Instead of /usr/include/c++/4.5/fenv.h including /usr/include/fenv.h,
>> clang finds /usr/include/c++/4.4/fenv.h instead.
> 
> On my system, it does use version 4.5:
> $ cat plop.c
> #include <fenv.h>
> 
> int main(){
> 	return 0;
> }
> 
> [17:46:38][sylvestre at korcula] /tmp$ clang -o plop plop.cpp 
> [17:46:41][sylvestre at korcula] /tmp$ cp plop.cpp plop.c
> [17:46:47][sylvestre at korcula] /tmp$ clang -o plop plop.c
> 
> Which gcc version do you have on your system ?
> (I am using my workstation to test, it might be a bit dirty).

I'm also using my work station. For testing purposes, I have 4.5, 4.4
and 4.3 installed. It first finds the 4.5 version, but then instead of
"include_next'ing" the intended /usr/include/fenv.h, it proceeds with
the next lower version, 4.4. Thanks to the same include-guards, the
chain stops there.

> 
>> The problem is, that clang still searches all possible
>> /usr/include/c++/4.X directories in descending version-order, where it
>> should stop after the first one found.
> No, looks like it continues. 
> It is adding paths into the vector:
>   std::vector<std::pair<IncludeDirGroup, DirectoryLookup> > IncludePath;
> 
> (you can try with the -v option of clang).

That's what I meant. It adds *loads* of guessed directories to the
search path. What I wanted to say is that it actually *should* stop.

> 
>> This was solved for me by forcing
>> the include-directories in the configure-options (refer to my
>> debdiff.patch for the details).
> 
> 
> When the options are set, it disables the automatic detection (which
> makes more than half of your patch useless)

Some of it, but not all. Only setting the options isn't enough. Didn't
take the time to figure out the exact dependencies, though... Sorry for
that.

On 05/27/2011 08:13 PM, Guillem Jover wrote:
> Hi!
>
> On Mon, 2011-05-23 at 16:02:56 +0200, Michael Wild wrote:
>> > On 05/23/2011 12:25 AM, Sylvestre Ledru wrote:
>> > diff -Nru clang-2.9/debian/rules.d/vars.mk
clang-2.9/debian/rules.d/vars.mk
>> > --- clang-2.9/debian/rules.d/vars.mk	2011-04-15 19:19:10.000000000
+0200
>> > +++ clang-2.9/debian/rules.d/vars.mk	2011-05-13 15:04:51.000000000
+0200
>> > @@ -68,6 +68,11 @@
>> >  confargs := \
>> >  	CC=$(DEB_HOST_GNU_TYPE)-gcc CXX=$(DEB_HOST_GNU_TYPE)-g++ \
>> >  	CPP=$(DEB_HOST_GNU_TYPE)-cpp \
>> > +
--with-c-include-dirs=/usr/include/$(DEB_BUILD_GNU_TYPE):/usr/include \
>> > +	--with-cxx-include-root=/usr/include/c++/4.5 \
>> > +	--with-cxx-include-arch=$(DEB_BUILD_GNU_TYPE) \
>> > +	--with-cxx-include-32bit-dir=32 \
>> > +	--with-binutils-include=/usr/include
>> >  	--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
> I don't think this is right, these two new DEB_BUILD_GNU_TYPE should
> probably be DEB_HOST_GNU_TYPE if those headers are the ones on the
> architecture built for (instead of build on).
>
> thanks,
> guillem

Ooops, sorry, I always keep mixing them up, and since I can't (won't)
test cross-compiled binaries, I haven't noticed.

Will try to come up with a reduced and fixed patch.

Michael