libstdc++-v3/std_cstddef.h's #include_next x libg++

libstdc++-v3/std_cstddef.h's #include_next x libg++

[Alexandre Oliva]

I haven't been able to build GCC along with libg++ with libstdc++-v3.
The problem is that directories that are searched by the preprocessor
because of -B switches are searched before those introduced with
-isystem, but libstdc++-v3's std_cstddef.h contains the line:

#include_next <stddef.h>

Since the preprocessor apparently only searches for stddef.h in
directories that appear in the search list after the one in which it
found the current header, it fails.

Maybe we shouldn't be transforming `-I's output by libstdc++-v3's
mkcheck in `-isystem' (so they'd always be searched before directories
introduced by -B)?  Maybe std_cstddef.h shouldn't be using
#include_next to include a header with a different name?  Maybe I'm
missing something? :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Benjamin Kosnik]

> #include_next <stddef.h>
> 
> Since the preprocessor apparently only searches for stddef.h in
> directories that appear in the search list after the one in which it
> found the current header, it fails.

Did the pre-processor's behavior WRT #include_next change recently? I'm 
also noticing broken/weird behavior, but relating to the 
--enable-cshadow-header stuff. 

Then again, this could be something completely different, relating to 
changes in the shadow-headers script...

Anyway.

The libstdc++-v3 header files are constructed in a more-funky-than-usual 
way because of an attempt (currently broken) to squester the C bits into 
some kind sanity for C++.

Background details can be found on Nathan's web page:

http://www.cantrip.org/cheaders.html

> output by libstdc++-v3's
> mkcheck in `-isystem' (so they'd always be searched before directories
> introduced by -B)?  

Hmm. Does your problem manifest itself without trying to build libg++, ie 
when running libstdc++-v3's 'mkcheck' script, which is run via 'make 
check-target-libstdc++-v3' ??

I'm a bit confused as to what your exact problem is: can you provide a 
bit more detail please?

> Maybe std_cstddef.h shouldn't be using
> #include_next to include a header with a different name?  

Hmm. Dunno. . . At some point, Nathan (or somebody) needs to get 
--enable-cshadow-headers working again. That way the #include_next stuff 
will actually be useful again.....


-benjamin

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Alexandre Oliva]

On Aug  9, 2000, Benjamin Kosnik <bkoz@redhat.com> wrote:

> Then again, this could be something completely different, relating to 
> changes in the shadow-headers script...

More likely to be related with the recent changes I made to the
top-level configure.in.  We're using mkcheck to find out what are the
-I flags to be passed to the C++ compiler, but configure.in arranges
for -I to be replaced with -isystem, since presumably the libstdc++
headers are all system headers.

> Hmm. Does your problem manifest itself without trying to build
> libg++

So far, I've only got the problem with libg++, but it'd probably
happen whenever you configure some C++ target library after
libstdc++-v3, so that the mkcheck script already exists.

> I'm a bit confused as to what your exact problem is: can you provide a 
> bit more detail please?

/home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/gcc/g++ -nostdinc++ -isystem /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3 -isystem /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3/libio -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/gnu-linux -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/cpu/i486 -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/std -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3 -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/libio -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/backward -isystem /home/guarana/aoliva/src/gcc-main/libstdc++-v3/ext -L/home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstd++-v3/src -L/home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstd++-v3/src/.libs -B/home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/gcc/ -B/usr/local/i686-pc-linux/bin/ -B/usr!
/local/i686-pc-linux/lib/ -isystem /usr/local/i686-pc-linux/include -L/home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/ld -c -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -nostdinc++ -I. -I../../libio -I/home/guarana/aoliva/src/gcc-main/libg++/src -I/home/guarana/aoliva/src/gcc-main/libg++/src/../../libio -I/home/guarana/aoliva/src/gcc-main/libg++/src/../../libstdc++ -I/home/guarana/aoliva/src/gcc-main/libg++/src/../src    /home/guarana/aoliva/src/gcc-main/libg++/src/AllocRing.cc
In file included from /home/guarana/aoliva/src/gcc-main/libstdc++-v3/libio/_G_config.h:19,
                 from /home/guarana/aoliva/src/gcc-main/libg++/src/std.h:22,
                 from /home/guarana/aoliva/src/gcc-main/libg++/src/AllocRing.cc:22:
/home/guarana/aoliva/src/gcc-main/libstdc++-v3/bits/std_cstddef.h:39:26: stddef.h: No such file or directory
make[2]: *** [AllocRing.o] Error 1
make[2]: Leaving directory `/l/x/tmp/gcc-lstdc++/i686-pc-linux/libg++/src'
make[1]: *** [src/libgxx.list] Error 2
make[1]: Leaving directory `/l/x/tmp/gcc-lstdc++/i686-pc-linux/libg++'
make: *** [all-target-libg++] Error 2

Running this huge command line with `-v -E -', I get:

#include "..." search starts here:
#include <...> search starts here:
 .
 /home/guarana/aoliva/src/gcc-main/libg++/src
 /home/guarana/aoliva/src/gcc-main/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++
 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/gcc/include
 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3
 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/gnu-linux
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/cpu/i486
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/std
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/backward
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/ext
 /usr/include
End of search list.

See, libstdc++-v3/bits is searched after gcc/include, so #include_next
doesn't work.  But replacing all occurrences of -isystem with -I, I
get the order expected by mkcheck:

 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3
 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/i686-pc-linux/libstdc++-v3/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/gnu-linux
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/config/cpu/i486
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/std
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/backward
 /home/guarana/aoliva/src/gcc-main/libstdc++-v3/ext
 .
 /home/guarana/aoliva/src/gcc-main/libg++/src
 /home/guarana/aoliva/src/gcc-main/libio
 /home/guarana/aoliva/src/gcc-main/libstdc++
 /home/guarana/aoliva/test/log/guarana/.tmp/gcc-lstdc++/gcc/include
 /usr/include

So, should I stop replacing -I with -isystem in the output of mkcheck,
in the top-level configure.in?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Benjamin Kosnik]

> More likely to be related with the recent changes I made to the
> top-level configure.in.  We're using mkcheck to find out what are the
> -I flags to be passed to the C++ compiler, but configure.in arranges
> for -I to be replaced with -isystem, since presumably the libstdc++
> headers are all system headers.

Hmm. Shouldn't you be using INCLUDES from libstdc++-v3/src/Makefile.am:

INCLUDES = \
	-D_GNU_SOURCE -nostdinc++ -I$(top_srcdir) \
	$(CSHADOW_INCLUDES) $(LIBIO_INCLUDES) \
	$(CONFIG_INCLUDES) $(TOPLEVEL_INCLUDES)	

This is the canonical include path for libstdc++-v3, not whatever is in 
mkcheck

> See, libstdc++-v3/bits is searched after gcc/include, so #include_next
> doesn't work.  But replacing all occurrences of -isystem with -I, I
> get the order expected by mkcheck:
[snip]
> So, should I stop replacing -I with -isystem in the output of mkcheck,
> in the top-level configure.in?

Yes. Please consider my point above though.

-benjamin

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Alexandre Oliva]

On Aug  9, 2000, Benjamin Kosnik <bkoz@redhat.com> wrote:

> Shouldn't you be using INCLUDES from libstdc++-v3/src/Makefile.am:

Great!  That's the clue I was missing.  Ok to install?

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Benjamin Kosnik]

> > Shouldn't you be using INCLUDES from libstdc++-v3/src/Makefile.am:
> 
> Great!  That's the clue I was missing.  Ok to install?

Please do..........

(FYI at some point, I'd like to make things like INCLUDES go into the 
top-level Makefile.am, instead of being duplicated in the src/Makefile.am 
and libio/Makefile.am. I think I tried to do this once but it wasn't 
working and I gave up quickly (should this be possible?) . When/if I do 
this, will this bit need to be changed? )

thanks, benjamin

Re: libstdc++-v3/std_cstddef.h's #include_next x libg++

[Alexandre Oliva]

On Aug 10, 2000, Benjamin Kosnik <bkoz@redhat.com> wrote:

>> > Shouldn't you be using INCLUDES from libstdc++-v3/src/Makefile.am:
>> 
>> Great!  That's the clue I was missing.  Ok to install?

> Please do..........

Done.  Sorry about the delay.  Since I had failed to Cc: gcc-patches,
this message got in the wrong folder, and that's where I regularly
check for pending patches :-(

> (FYI at some point, I'd like to make things like INCLUDES go into the 
> top-level Makefile.am, instead of being duplicated in the src/Makefile.am 
> and libio/Makefile.am. I think I tried to do this once but it wasn't 
> working and I gave up quickly (should this be possible?) . When/if I do 
> this, will this bit need to be changed? )

Yep, it will have to be changed.

The way to go is probably to do it in libstdc++-v3's configure.in, and
get it AC_SUBSTed in all Makefiles.  Then we probably won't have to
bother changing the way INCLUDES are handled.


Next step is to arrange for libstdc++-v3's configure to output a
`.'-able script that sets LD_LIBRARY_PATH or equivalent to all
directories containing run-time libraries.  Then we'd arrange for the
top-level's SET_LIB_PATH to source any such scripts when appropriate.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me