bug-hurd
[Top][All Lists]
Advanced

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

Re: Glibc without installed headers


From: Roland McGrath
Subject: Re: Glibc without installed headers
Date: Tue, 23 Jul 2002 02:04:44 -0400 (EDT)

> Tadaa!  Here is the more detailed info.  If you try to do
> 
> $ make install-headers no_deps=t
> 
> in the configured Hurd sources, you get:
> 
> make[1]: Entering directory `/gnu/build/hurd-obj/libtrivfs'
> i386-gnu-gcc -O -E -x c  -I. -I../../hurd/libtrivfs -I.. -I../../hurd 
> -I../include -I../../hurd/include -D_GNU_SOURCE -D_IO_MTSAFE_IO 
> -D_FILE_OFFSET_BITS=64   -imacros ../../hurd/libtrivfs/fsmutations.h  
> -DSERVERPREFIX=S_ ../../hurd/hurd/fs.defs -o fs.sdefsi
> In file included from ../../hurd/hurd/fs.defs:25:
> ../../hurd/hurd/hurd_types.defs:234:26: bits/utsname.h: No such file or 
> directory
> make[1]: *** [fs.sdefsi] Error 1
> make[1]: Leaving directory `/gnu/build/hurd-obj/libtrivfs'
> make: *** [libtrivfs-install-headers] Error 2

Ah!  This is new, and it's my fault.  Previously all headers the Hurd
installed were simple files to be copied.  Now trivfs has some headers that
are mig-generated, and you can't do mig generation without a proper full
set of headers installed.  I think what we should do is have
install-headers, or a differently-named new target, install just the plain
headers and not the generated ones.  Or it might be sufficient just to do
make install-headers in the hurd subdir to build libc.  Try that.

> Now, when trying to compile glibc:

bits/stdio_lim.h should have been generated before anything was compiled,
because it appears in $(common-generated) (see the end of Rules).
I will look into this when I get a chance.

> Note that there is still the problem that the RPC stubs in mach/ are not
> generated (see libc-alpha), and I am very confused by the makefiles.

Well, those makefiles are just going to confuse you and we have to accept
that. :-)  I think that problem is real, and I will have to diddle with it
and find the right solution.  However, just doing make -k twice ought to
make it win.

> It seems that this problem occurs only with gcc 3.1, which is obscure.

I think it was always a problem and I don't know why we didn't see it before.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]