Bug 223279
| Summary: | devel/boost-libs fails to build on powerpc64 since update to 1.65.1 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Justin Hibbits <jhibbits> | ||||||||
| Component: | Individual Port(s) | Assignee: | FreeBSD Office Team <office> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Only Me | CC: | andreast, gerald | ||||||||
| Priority: | --- | ||||||||||
| Version: | Latest | ||||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Attachments: |
|
||||||||||
Comment on attachment 187520 [details] poudriere build log > - addr2line builds : no Can you attach bin.v2/config.log located under WRKSRC? Created attachment 187527 [details]
config.log
Scanning the log for addr2line, I came across the following giveaway:
gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/has_addr2line.o
"g++6" -O0 -fno-inline -Wall -g -fPIC -m64 -pipe -DLIBICONV_PLUG -Wl,-rpath=/usr/local/lib/gcc6 -fno-strict-aliasing -DLIBICONV_PLUG -Wl,-rpath=/usr/local/lib/gcc6 -std=gnu++11 -pipe -DLIBICONV_PLUG -Wl,-rpath=/usr/local/lib/gcc6 -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -I"." -c -o "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/has_addr2line.o" "libs/stacktrace/build/has_addr2line.cpp"
gcc.link bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe
"g++6" -o "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe" -Wl,--start-group "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/has_addr2line.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64
Jamfile</wrkdirs/usr/ports/devel/boost-libs/work/boost_1_65_1/libs/stacktrace/build>.mp_simple_run_action bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line.output
bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe > bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line.output
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.21 required by /wrkdirs/usr/ports/devel/boost-libs/work/boost_1_65_1/bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe not found
...failed Jamfile</wrkdirs/usr/ports/devel/boost-libs/work/boost_1_65_1/libs/stacktrace/build>.mp_simple_run_action bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line.output...
So, looks like it needs a -rpath somewhere...
Created attachment 188669 [details]
Proposed fix
This is not the nicest patch. It touches Mk/bsd.gcc.mk (adds RPATH variable), but it does fix the build. Probably needs an exprun at the minimum.
Adding Gerald since the patch touches bsd.gcc.mk Comment on attachment 188669 [details] Proposed fix > +MAKE_ARGS+= xdll-path=${RPATH} Why not use ${_GCC_RUNTIME} directly? make(1) usually postpones variable expansion unless it's used in .if/.for conditionals or target dependencies. Comment on attachment 188669 [details] Proposed fix > +.if ${COMPILER_TYPE}==gcc This should be CHOSEN_COMPILER_PATH in case USES=compiler switches from Clang to GCC or vice versa. Maybe also avoid .if conditional to get rid of immediate variable expansion e.g., MAKE_ARGS+= ${MAKE_ARGS_${CHOSEN_COMPILER_PATH}} MAKE_ARGS_gcc= xdll-path=${_GCC_RUNTIME} After that .include line changes will no longer be required. (In reply to Jan Beich from comment #6) Err, s/CHOSEN_COMPILER_PATH/CHOSEN_COMPILER_TYPE/ ;) (In reply to Jan Beich from comment #5) I was operating under the assumption that _-prefixed variables are intended to be private to the include file. If that's not the general case, I'll gladly change it. A number of ports already uses ${_GCC_RUNTIME}. While the use of internal variable is discouraged it's not forbidden given lack of better alternative. For one, USES=fortran has ${LOCALBASE}/lib/gcc${_GCC_VER} which is just as ugly.
A commit references this bug: Author: jbeich Date: Sun Dec 10 18:40:51 UTC 2017 New revision: 455905 URL: https://svnweb.freebsd.org/changeset/ports/455905 Log: devel/boost-libs: pass RPATH when building with GCC "g++6" -o "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe" -Wl,--start-group "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/has_addr2line.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64 /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.21 required by /wrkdirs/usr/ports/devel/boost-libs/work/boost_1_65_1/bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe not found [...] Error: Missing: lib/libboost_stacktrace_addr2line.a Error: Missing: lib/libboost_stacktrace_addr2line.so Error: Missing: lib/libboost_stacktrace_addr2line.so.%%BOOST_SHARED_LIB_VER%% PR: 223279 Submitted by: jhibbits (based on) Changes: head/devel/boost-libs/Makefile Thanks, Jan! (In reply to Justin Hibbits from comment #8) > I was operating under the assumption that _-prefixed variables are > intended to be private to the include file. And you're right. Using ${_GCC_RUNTIME} in individual ports is a mistake (though introducing another variable that just mirrors that, if apparently necessary like here, probably is a cure worse than the disease?) Could we avoid all of this is bug #200171 was addressed and the rpath included by the gcc, g++,... drivers? A commit references this bug: Author: jbeich Date: Mon Dec 11 00:07:17 UTC 2017 New revision: 455916 URL: https://svnweb.freebsd.org/changeset/ports/455916 Log: MFH: r455905 devel/boost-libs: pass RPATH when building with GCC "g++6" -o "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe" -Wl,--start-group "bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/has_addr2line.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64 /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.21 required by /wrkdirs/usr/ports/devel/boost-libs/work/boost_1_65_1/bin.v2/libs/stacktrace/build/gcc-6.4.0/debug/addr2line_exe not found [...] Error: Missing: lib/libboost_stacktrace_addr2line.a Error: Missing: lib/libboost_stacktrace_addr2line.so Error: Missing: lib/libboost_stacktrace_addr2line.so.%%BOOST_SHARED_LIB_VER%% PR: 223279 Submitted by: jhibbits (based on) Approved by: ports-secteam blanket Changes: _U branches/2017Q4/ branches/2017Q4/devel/boost-libs/Makefile (In reply to Gerald Pfeifer from comment #12) Forcing the gcc ports to include the rpath themselves would likely solve this problem, yes. It would also fix other ports, including libreoffice. |
Created attachment 187520 [details] poudriere build log boost-libs 1.65.1 introduces the stacktrace-addr2line library, which for some reason does not build on powerpc64 (no indication why). The build succeeds, but the package fails because the library does not exist. Log is attached.