On 08/25/17 11:12, Roger Leigh via Boost wrote:
On 25/08/2017 06:25, Gavin Lambert via Boost wrote:
On 25/08/2017 17:42, Antony Polukhin wrote:
FreeBSD has the required function definition here: https://github.com/lattera/freebsd/blob/master/include/unwind.h#L137 It is available if _GNU_SOURCE or _BSD_SOURCE macro is defined.
I have no idea why _BSD_SOURCE is not defined on FreeBSD. If there's some file that defines those macro, please send me the file name and path, and I'll include it in the Stacktrace library before the inclusion of unwind.h,
_GNU_SOURCE and _BSD_SOURCE (among others) are never defined in the library headers -- they are application/project-level settings to indicate that the application author is willing to sacrifice portability in order to have access to additional features, and which of the (sometimes incompatible) extensions they prefer.
Library authors don't get to choose (except when building private translation units); they have to adapt to whatever the application picked.
ie. you should probably be testing those macros and either selecting alternate functionality or emitting a more comprehensible warning/error if not defined, rather than let it generate a regular missing symbol error.
It's within a source file rather than a header, so it's entirely appropriate to define _GNU_SOURCE or _BSD_SOURCE before including any headers, isn't it?
Yes, but that is the user's choice which macro to define, if any.
Note a work in progress fix here does just this; the error it's making is undefing it after the includes: https://reviews.freebsd.org/differential/changeset/?ref=313538&whitespace=ignore-most
That is not correct, IMO. The user's application may define a different macro to select another API flavor; additionally defining _GNU_SOURCE makes a conflict and the outcome is generally unknown. If the API is required by the library, I can see two solutions: 1. Make the API selection mandatory for users and act accordingly to the user's choice in headers. I.e., as Gavin suggested, test the macros and error out on unsupported combination. 2. Move that part of the code to a compiled library and define the necessary macros for that library in the Jamfile or .cpp files. The public headers become neutral to the selected API in this case.
Though I'm not sure why Boost's build system wouldn't set _GNU_SOURCE or _BSD_SOURCE when building all cpp source files on GNU/BSD systems.
Because it is library's choice what API it will use internally.