[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc-3.4 build failure on hurd-i386

On Wed, 4 May 2005, Michael Banck wrote:

> On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
> Anyway, back to the gcc-3.4 build log:
> > ./xgcc -B./ -B/usr/i586-gnu/bin/ -isystem /usr/i586-gnu/include
> >   -isystem /usr/i586-gnu/sys-include
> >   -L/build/mbanck/gcc-3.4-3.4.3/build/gcc/../ld -O2 -DIN_GCC    -W
> >   -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> >   -Wold-style-definition  -isystem ./include  -I. -I. -I../../src/gcc
> >   -I../../src/gcc/. -I../../src/gcc/../include   -g0
> >   -finhibit-size-directive -fno-inline-functions -fno-exceptions
> >   -fno-zero-initialized-in-bss -fno-unit-at-a-time  \
> >   -c ../../src/gcc/crtstuff.c -DCRT_BEGIN \
> >   -o crtbegin.o
> > In file included from ../../src/gcc/crtstuff.c:62:
> >   ../../src/gcc/tsystem.h:79:19: stdio.h: No such file or directory
> I see now: /include appears to be hard-coded as the sole system include
> search path for *-gnu-*, while my system has a real /usr and thus no
> /include directory.  If I link /usr/include to /, it builds fine (well
> crtbegin.o at least).
> Debian GNU/Hurd is (currently) trying to support both a real /usr and a
> /usr->. symlink (the install CDs make a symlink, but crosshurd users can
> choose), so I wonder what the right fix is, perhaps remove whatever
> special policy enforcement there is for /include for Debian only?
> What do the other Hurd porters think?

If /usr is a symlink to / and gcc uses /usr/include, it will work.
If /usr is a real directory and gcc uses /usr/include, it will work as well.

So, if gcc is going to use a single directory as the include path, I think
it should (still) be /usr/include, at least on Debian.

I think we have never been ready to have /usr as a symlink to / on a
development machine. Two examples:

* dpkg-shlibdeps needs to be patched and the build logs are full of
  ugly junk when debian/rules reaches dh_shlibdeps.

* The last libtool that was build on a system in which /usr was a
  symlink had sed hardcoded as /usr/bin/sed (because it was "detected"
  to be there, due to the symlink), and therefore it was horribly broken
  on a system where /usr was a real directory.

Because of the risk of things like this happening, I consider a system
where /usr is a symlink completely inapropriate for building packages,
as those packages might only work on a system where /usr is also a symlink.

Reply to: