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

Re: conflicting definitions in /usr/include/



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.

You should definitely not include linux headers in a userspace program if you want it to run on the Hurd or BSD ports.

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.

Can that simply be disabled on non-linux ports?

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. Ofcourse,
when BSD and Hurd get added to Debian, you can do it again :)

__u32 is a typedef to uint32_t. Is there a good reason why the code isn't just using uint32_t?

	---Nathan



Reply to: