Bug#721886: FTBFS on kfreebsd-*: glibtop_machine.h:26:19: fatal error: nlist.h: No such file or directory

[Guillem Jover]

Hi!

On Thu, 2013-09-05 at 19:52:13 +0200, Michael Biebl wrote:
> Am 05.09.2013 19:42, schrieb Julien Cristau:
> > On Thu, Sep  5, 2013 at 19:40:18 +0200, Michael Biebl wrote:
> >> Am 05.09.2013 19:29, schrieb Julien Cristau:
> >>> On Thu, Sep  5, 2013 at 17:50:18 +0200, Michael Biebl wrote:
> >>>> Am 05.09.2013 17:29, schrieb Robert Millan:
> >>>>> -#include <nlist.h>
> >>>>> +#include <bsd/nlist.h>

Please try to avoid this, which cannot be easily upstreamed, or if it
can be upstreamed it unnecessarily pollutes the source.

> >>>> Does that also work with FreeBSD so can be pushed upstream?
> >>>> Apparently libgtop2 has native FreeBSD support and I wonder if nslist.h
> >>>> is using a different location on  FreeBSD.
> >>>>
> >>> In xorg-server added `pkg-config --cflags libbsd-overlay` to CPPFLAGS
> >>> from debian/rules.  Lets the code expecting bsd headers on bsd work
> >>> without patching.

Yes, that's the ideal solution, which generally avoids any patching.

> >> That's confusing tbh. Why is libbsd-dev using different paths in the
> >> first place which requires such hacks?
> >>
> > Because the normal bsd paths would conflict with gnu libc-dev headers
> > (maybe not for nlist.h, but for others).
> 
> Why do libc-dev and libbsd-dev have conflicting files in the first place
> and why not move just the conflicting (BSD) files to bsd/ ?

Most header files provided by libbsd-dev are overlays over the libc
ones. For example strlcpy() and friends in bsd/string.h, or slightly
different implementations like bsd/sys/queue.h.

Then there's partial implementations like bsd/libutil.h which does not
conflict with anything, but exposing it directly under /usr/include
can confuse software that might assume functionality in libc just
because the file is there, for example I think perl suffered from this
in Debian at some point.

And there's files already shipped by other pre-existing libraries,
like bsd/nlist.h, provided by libelfg0-dev and libelf-dev. And no,
Replaces does not cut it, because once you remove libbsd-dev then
the other libraries will be missing the header. This was a mistake I
corrected by namespacing it under bsd/ (the aforementioned link on
the list).

After all these cases, the only remaining non-conflicting headers are
readpassphrase.h, vis.h and md5.h. For md5.h taking over the global
namespace seems wrong (it probably belongs in the to-be-uploaded
libmd), at which point having the remaining two namespaced seems safer,
more future-proof and nicer to other projects.

> Apparently libgtop2 built just fine in the past with libbsd-dev, so this
> looks like a recent regression in that package.

I went over any package explicitly declaring a Build-Depends on
libbsd-dev when I did those changes, if libgtop2 is directly using
stuff from libbsd-dev but not declaring it explicitly, that's hardly
my fault? :)

Thanks,
Guillem