`man 3 asprintf` claims that asprintf() is available under both GNU and *BSD systems, but it is not available when using bsd/stdio.h. This provides the following QA notice when compiling a port of btxld on Gentoo: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * btxld.c:557:2: warning: implicit declaration of function 'asprintf' [-Wimplicit-function-declaration] It looks like we can turn this on by setting __USE_GNU, but that would have consequences beyond providing asprintf(). It might be best to patch the bsd/stdio.h header to provide a asprintf() function prototype.
(In reply to comment #0) > `man 3 asprintf` claims that asprintf() is available under both GNU and *BSD > systems, but it is not available when using bsd/stdio.h. This provides the > following QA notice when compiling a port of btxld on Gentoo: > > * QA Notice: Package triggers severe warnings which indicate that it > * may exhibit random runtime failures. > * btxld.c:557:2: warning: implicit declaration of function 'asprintf' > [-Wimplicit-function-declaration] > > It looks like we can turn this on by setting __USE_GNU, but that would have > consequences beyond providing asprintf(). It might be best to patch the > bsd/stdio.h header to provide a asprintf() function prototype. __USE_GNU is an internal implementation detail, the correct way to make the GNU namespace visible is through _GNU_SOURCE. The problem is that defining that in the header does not guarantee that this header has been included before <features.h> (which is required for its proper use), what could work instead is to define it in the libbsd.pc files, but as you say this could have unintended consequences, and IMO should be done by the application itself. Defining a prototype for a function not provided by the library could also cause issues if the signature of system prototype diverges at some point from the libbsd one. For autoconf based build systems the correct option is to use the AC_USE_SYSTEM_EXTENSIONS macro, which will enable any such macros. But I'd assume that project is not using autoconf if it's of bsd descent. What I'm wondering though, is why defining _GNU_SOURCE in the package/ebuild/whatever CPPFLAGS/CFLAGS is an issue, that would seem like the next best option to me.
No response in several months, and given the arguments on my last comment, I'm marking it resolved/invalid.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.