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

Re: conflicting definitions in /usr/include/



On Wed, Sep 11, 2002 at 07:16:36PM +1000, Martijn van Oosterhout wrote:
> On Wed, Sep 11, 2002 at 03:27:22AM -0400, Noah Meyerhans wrote:
> > On Wed, Sep 11, 2002 at 11:37:29AM +1000, Martijn van Oosterhout wrote:
> > > The reason why they both have it is that the linux/* definition are
> > > the kernel ones, the netinet/in.h ones are what glibc copied from
> > > the kernel ones. Userspace programs should *never* include linux/*
> > > headers. If you need an interface not in glibc, you should bug them
> > > to make appropriate copies.
> > 
> > That's what I expected.
> > 
> > So I've successfully updated traceroute6 to use all the right bits
> > from glibc and not touch /usr/include/linux/ at all. tracepath and
> > tracepath6 are a bit harder, though, since they make use of Linux error
> > queues as defined in /usr/include/linux/errqueue.h. I can't seem to
> > find any interface between the glibc headers and the kernel. Does one
> > exist, or will these programs continue to require linux/errqueue.h?
> 
> Well, if there is no alternative, I guess you can't avoid it. It also
> makes the code linux specific. But when it comes to networking stuff
> which works cross platform/architechture, use the interfaces provided.
> 
> > > Maybe the fix is as simple as deleting any lines saying #include
> > > <linux/*> and remove all those editted header files too.
> > 
> > It was almost that easy, but some types needed to be updated since the
> > code was using things like __u32, which is defined in linux/types.h.
> 
> If it works across all the required platforms, you've suceeded. Of
> course, when BSD and Hurd get added to Debian, you can do it again :)

Good though, slight flaw: using GLIBC headers also won't (necessarily)
work, since at least three of the BSD ports are currently going with native
libc rather than GNU libc.

However, in the case above, you should also certainly be using one of
the types from the various published standards (and possibly an ifdef or
autoconf wrapper to make sure the proper standard is available); my first
guess for the above would be something like u_int32_t (ISO C standard).

Granted, error queues are probably going to be Linux-specific for a while,
and the entire section of code that uses them should just be wrapped in a
suitable autoconf ifdef or somesuch, probably...
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/

Attachment: pgpTK9NDtoUlJ.pgp
Description: PGP signature


Reply to: