1.65 build failure on FreeBSD 11.1
The error is "boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no
member named '_Unwind_Backtrace' in the global namespace". The details
are below. A creeping Linux-ism?
Regards,
Roger
$ clang++ --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
$ uname -a
FreeBSD brill 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21
02:08:28 UTC 2017
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
-- Building boost (Unix) with toolset=clang cxxflags=
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
linkflags=
-L/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib
Performing configuration checks
- 32-bit : no
- 64-bit : yes
- arm : no
- mips1 : no
- power : no
- sparc : no
- x86 : yes
- symlinks supported : yes
- C++11 mutex : no
- lockfree boost::atomic_flag : yes
- Boost.Config Feature Check: cxx11_auto_declarations : no
- Boost.Config Feature Check: cxx11_constexpr : no
- Boost.Config Feature Check: cxx11_defaulted_functions : no
- Boost.Config Feature Check: cxx11_final : no
- Boost.Config Feature Check: cxx11_hdr_mutex : no
- Boost.Config Feature Check: cxx11_hdr_tuple : no
- Boost.Config Feature Check: cxx11_lambdas : no
- Boost.Config Feature Check: cxx11_noexcept : no
- Boost.Config Feature Check: cxx11_nullptr : no
- Boost.Config Feature Check: cxx11_rvalue_references : no
- Boost.Config Feature Check: cxx11_template_aliases : no
- Boost.Config Feature Check: cxx11_thread_local : no
- Boost.Config Feature Check: cxx11_variadic_templates : no
- has_icu builds : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
- zlib : yes
- bzip2 : yes
- lzma : yes
- iconv (libc) : yes
- icu : yes
- xlocale supported : yes
- native-atomic-int32-supported : yes
- native-syslog-supported : yes
- pthread-supports-robust-mutexes : yes
- compiler-supports-visibility : yes
- compiler-supports-ssse3 : yes
- compiler-supports-avx2 : yes
- gcc visibility : yes
- long double support : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
- libbacktrace builds : no
- addr2line builds : yes
- WinDbg builds : no
- WinDbgCached builds : no
Component configuration:
- atomic : building
- chrono : building
- container : building
- context : building
- coroutine : building
- date_time : building
- exception : building
- fiber : building
- filesystem : building
- graph : building
- graph_parallel : building
- iostreams : building
- locale : building
- log : building
- math : building
- metaparse : building
- mpi : building
- program_options : building
- python : not building
- random : building
- regex : building
- serialization : building
- signals : building
- stacktrace : building
- system : building
- test : building
- thread : building
- timer : building
- type_erasure : building
- wave : building
[...]
clang-linux.compile.c++.without-pth
bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o
"/usr/bin/CC" -c -x c++
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
-O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
-DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o
"bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o"
"libs/stacktrace/build/../src/addr2line.cpp"
In file included from libs/stacktrace/build/../src/addr2line.cpp:10:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213:
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7:
error: no member named '_Unwind_Backtrace' in the global namespace
::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback,
&state);
~~^
1 error generated.
...skipped
libboost_stacktrace_addr2line.so.1.65.0
for lack of
libboost_stacktrace_addr2line.so
for lack of
libboost_stacktrace_addr2line.so.1.65.0...
clang-linux.compile.c++.without-pth
bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o
"/usr/bin/CC" -c -x c++
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
-O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
-DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o
"bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o"
"libs/stacktrace/build/../src/basic.cpp"
In file included from libs/stacktrace/build/../src/basic.cpp:9:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20:
In file included from
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213:
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7:
error: no member named '_Unwind_Backtrace' in the global namespace
::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback,
&state);
~~^
1 error generated.
...skipped
libboost_stacktrace_basic.so.1.65.0
for lack of
libboost_stacktrace_basic.so
for lack of
libboost_stacktrace_basic.so.1.65.0...
common.mkdir bin.v2/libs/timer
2017-08-24 12:42 GMT+00:00 Roger Leigh via Boost
The error is "boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace". The details are below. A creeping Linux-ism? <...> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ 1 error generated.
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, Otherwise try defining the macro manually. -- Best regards, Antony Polukhin
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.
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
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.
2017-08-25 10:12 GMT+00:00 Andrey Semashev via Boost
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.
I'll take this solution for header-only version of the library.
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.
And this solution for the compiled llibrary version. Thanks for the suggestions, patches will be applied soon! -- Best regards, Antony Polukhin
participants (5)
-
Andrey Semashev -
Antony Polukhin -
Gavin Lambert -
rleigh＠codelibre.net -
Roger Leigh