Re: [boost] 1.65 build failure on FreeBSD 11.1

Subject: Re: [boost] 1.65 build failure on FreeBSD 11.1
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-08-25 10:12:50

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.