Re: [boost] 1.65 build failure on FreeBSD 11.1

Subject: Re: [boost] 1.65 build failure on FreeBSD 11.1
From: Roger Leigh (rleigh_at_[hidden])
Date: 2017-08-25 08:12:37

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?

A quick grep through the Boost sources shows multiple examples of this 
type of usage.

% grep -R _GNU_SOURCE *
tools/build/src/engine/jamgram.c:#  if defined __GLIBC__ && defined 
_STRING_H && defined _GNU_SOURCE
tools/build/src/engine/boehm_gc/dyn_load.c:     && !defined(_GNU_SOURCE)
tools/build/src/engine/boehm_gc/dyn_load.c:#   define _GNU_SOURCE
Jamroot:      <toolset>como-linux:<define>_GNU_SOURCE=1
libs/asio/test/Jamfile.v2:    <os>LINUX:<define>_GNU_SOURCE=1
libs/program_options/src/parsers.cpp:// and in case they came from glibc 
and _GNU_SOURCE was defined.)
libs/config/test/config_info.cpp:   PRINT_MACRO(_GNU_SOURCE);
libs/container/src/dlmalloc_2_8_6.c:#define _GNU_SOURCE /* Turns on 
mremap() definition */
boost/python/detail/python22_fixed.h:#ifndef _GNU_SOURCE
boost/python/detail/python22_fixed.h:# define _GNU_SOURCE    1

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

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.

Regards,
Roger