| Summary: | dev-libs/boost-1.66.0 on mingw-w64 - ? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | hanetzer |
| Component: | Current packages | Assignee: | David Seifert <soap> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | cpp+disabled, office |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/7520 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Likely obsolete. |
While I realize dev-libs/boost-1.66.0 is currently unkeyworded, I feel its my duty to report issues with it. When using a crossdev-built x86_64-w64-mingw32 toolchain, when emerging boost a few issues arise. With an unmodified boost-1.66.0.ebuild, build fails during some pthread macro expansion as below: "x86_64-w64-mingw32-g++" -O2 -pipe -fomit-frame-pointer -std=c++14 -finline-functions -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DNDEBUG -I"." -c -o "bin.v2/libs/thread/build/gcc-mingw-gnu-7.3/gentoorelease/boost.locale.icu-off/pch-off/threadapi-pthread/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" libs/thread/src/pthread/thread.cpp:540:2: error: #error #error This is due to boost currently looking for some old mingw-w64 pthread libraries, and must be fixed upstream. Setting target-os=windows in src_configure if kernel_Winnt is true halts the build during the configuration stage, with the following message: error: Name clash for '<pstage/lib>libboost_atomic.dll.a' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Setting address-model=64 manually allows the build to continue further until actual completion, however, this will be using the win32 threadapi. Obviously hard-coding these like I did in the ebuild is not the right way to actually fix the issue, so I'd like to make the following suggestions: 1. manually detect what the operating system is and use it to explicitly set target-os properly 2. manually detect the proper address-model variable (prolly some toolchain.eclass function) and set it explicitly.