On Son, 2006-03-19 at 12:28 -0600, DJ Lucas wrote:
> Jürg Billeter wrote:
> > 
> > Yes, as I've written before, iproute2 is one of the problematic
> > packages. Besides fixing the includes[1] you need to remove the local
> > copy of the not sanitized kernel headers, i.e. rm -r include/linux[2]

> I'm using with the compat headers (modified from Jurg's version of the 
> script) and glibc-2.3.6.  Did not use Jurg's patch, well I did, but came 
> across the same types of errors.  After adding <net/if.h> to ipaddress.c 
> and ifstat.c, here is the remaining error.
> 
> /usr/include/linux/socket.h:2:2: warning: #warning "You should include 
> <sys/socket.h>.  This time I will do it for you. "
> ipaddress.c: In function 'print_link_flags':
> ipaddress.c:96: error: 'IFF_DYNAMIC' undeclared (first use in this function)
> ipaddress.c:96: error: (Each undeclared identifier is reported only once
> ipaddress.c:96: error: for each function it appears in.)
> make[1]: *** [ipaddress.o] Error 1
> 
> IFF_DYNAMIC is not in /usr/include/net/if.h.

Well, glibc 2.3.6 is too old, then. The sanitized headers my script
generate are not just generic sanitized kernel headers, they are
specific to glibc and as we've just found out, it only works with 2.4
even.

> [...] Also, no need to 
> remove the included kernel headers.  That is the proper placement if a 
> package _needs_ kernel headers, correct?

Not sure about that. Including kernel headers in a userspace package is
just a convenience that it can be compiled on not up-to-date or
incomplete/broken systems. It probably makes sense to do that for some
packages but there should be a configure check or option to not include
the copies if the system is up-to-date, IMO.

> 
> Next error was in sysklogd:
> 
> gcc  -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce -DFSSTND 
>   -c ksym_mod.cIn file included from ksym_mod.c:97:
> module.h:31:24: error: asm/atomic.h: No such file or directory
> make: *** [ksym_mod.o] Error 1
> 
> I didn't look at the code, a simple "sed -i /atomic.h/d module.h" 
> 'fixed' the compilation problem.  Need to double check why it thinks it 
> needs atomic.h.

That's funny; the kernel headers patch I use in paldo is the one you
submitted in 2003 to lfs (origin LSB), and this version works just fine
as it doesn't contain a atomic.h reference :)

Regards,

Jürg

--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to