include/bsd/nlist.h


Log

Author Commit Date CI Message
James Clarke 61d378f5 2019-02-03T00:11:15 Re-allow direct use of nlist.n_name in <nlist.h> Commit e8d340de ("Remove a.out support from nlist()") introduced a copy of the definition of nlist from a.out.h. However, as well as having n_name inside n_un, on the various BSDs n_name could also be accessed as a direct member of nlist, and this is made use of by FreeBSD's usr.bin/netstat/main.c. Thus we should also add the same enclosing anonymous union. [guillem@hadrons.org: - Add a minimal unit test. ] Closes: !4 Signed-off-by: Guillem Jover <guillem@hadrons.org>
Guillem Jover 11ec8f1e 2018-03-06T01:41:35 Handle systems missing <sys/cdefs.h> This is a non-portable header, and we cannot expect it to be provided by the system libc (e.g. musl). We just need and rely on declaration that we have defined ourselves in our own <bsd/sys/cdefs.h>. So we switch to only ever assume that. Fixes: https://bugs.freedesktop.org/105281
Guillem Jover e8d340de 2017-06-05T05:30:27 Remove a.out support from nlist() Some libc libraries do not have an <a.out.h> header. And a.out as an executable format is very much obsolete on pretty much all currently supported systems, even if they might still support loading such objects. Remove the a.out support to increase portability.
Guillem Jover e4475738 2017-01-20T02:20:12 Try <linux/a.out.h> if <a.out.h> is not present At least musl ships the former but not the latter.
Guillem Jover e7f39760 2012-03-23T10:31:42 Add email address to my name
Guillem Jover b891772a 2011-05-29T02:49:14 Remove blank lines at EOF
Guillem Jover f7caf2b3 2011-02-23T11:07:30 Move all header files to /usr/include/bsd/ and deprecate /usr/include/ First stage of the transition to avoid possible clashes with other software by moving out of the way the remaining headers from /usr/include/. At least nlist.h is known to cause file conflicts with some libelf implementations. libutil.h is not really complete and might cause confusion if software detects its availability w/o someone actually checking. And lastly vis.h is not known to cause any problem and it's complete, but better be safe than sorry. The compatibility headers will be removed in a later release.