wrong/old files in include/linux

[Thomas Haller]

On Tue, 2014-09-23 at 10:27 -0400, Michael Richardson wrote:
> Thomas Graf <tgraf at suug.ch> wrote:
>     >> Under include/linux, we have:
>     >> %ls include/linux
>     >> can/         if_addr.h    if_link.h    ipv6.h       netlink.h    snmp.h
>     >> fib_rules.h  if_arp.h     if_vlan.h    neighbour.h  pkt_cls.h    tc_act/
>     >> gen_stats.h  if_bridge.h  ip.h         netfilter/   pkt_sched.h  tc_ematch/
>     >> genetlink.h  if_ether.h   ip_mp_alg.h  netfilter.h  rtnetlink.h
>     >>
>     >> These are mostly bad/poor copies of files from /usr/include.
>     >> I appreciate that perhaps they are necessary in some places in order to build
>     >> properly, but I wonder if could be in another directory, -I added for just
>     >> that situation?  Maybe they don't need to exist at all?
>     >>
>     >> This is the only thing that keeps me from building against in-tree libnl.
>     >> The -Iblahblah/libnl/include finds the incomplete if.h (which I've deleted
>     >> locally above), rather than the one from my exported kernel /usr/include.
> 
>     > The reason these copies exist is because libnl frequently receives
>     > support for recent new kernel features and the glibc headers take
>     > a while to be updated. Some of the copies can probably be removed at
> 
> Yes, this makes sense.
> 
>     > this point but it is difficult to figure out which as it might break
>     > builds that are currently functionality.
> 
>     > Can you provide the compile error/warning? I thought we fixed the if.h
>     > conflict.
> 
> if.h was missing lots of things, such as the ifreq definition.
> This affects programs built against libnl, with libnl's include directory,
> particularly in various cross-build environments.

libnl3 has a private copy of some kernel header files. Note that these
headers are entirely private and only used to build libnl3 itself.
Especially, they are not installed in libnl's include directory.


> I suggest that the extra kernel includes not go into the main libnl include
> directory, but rather into some other directory.  I think I have a patch to
> do this, which I can push to github.

This sounds like you are trying to build your application using the
include path to the libnl source dir: -I/usr/src/libnl-3.2.25/include
Don't do that. Instead: build libnl3, `make install` and then use 
-I$PREFIX/include/libnl3


Updating out-of-date kernel headers can make sense if you have a
specific issue(??). A missing 'struct ifreq' however, has no effect at
all on the libnl3 build -- because libnl3 does not use that struct.


If you feel strongly about it, we can update if.h, so that
-I/usr/src/libnl-3.2.25/include works for you. I guess, that is
convenient.
But that is just a particular fix, not the real solution. The solution
is to use -I$PREFIX/include/libnl3


Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20140923/333bf70b/attachment.sig>