Make sure you completed the following tasks
Environment and version details
- Operating System+version: RHEL 10
- Compiler+version: GCC 15
- Shell: bash
- B2 Version: the one embedded in boost 1.89 beta
Brief problem description
In boost recently there was some modular work. One of the nasty consequences of this is that now there are more dependencies in the generated libboost_XXX.so, more than before, and actually more than necessary. See for example these cases:
Technically, this is a boost issue, to be fixed in each boost library. Yet, I was trying to workaround it globally in an easy way, by using the linker flag --as-needed which would fix issues in most cases. I tried passing this argument as part of the b2 linkflags but... -Wl,--as-needed is passed at the end of the command line. Indeed, looking here:
https://github.com/bfgroup/b2/blob/c803de9a3d704a89bfc43831f8c198bf0078c007/src/tools/gcc.jam#L1068C292-L1068C318
We seem to pass $(OPTIONS) $(USER_OPTIONS) at the end. -Wl,--as-needed is an argument whose position on the command line matters: if passed at the end, it affects only the "implicit" libraries the linker will add automatically (things like -lstdc++, -lgcc or -lc). Looking at the equivalent C/CXXFLAGS for the compile command lines, we seem to pass $(OPTIONS) $(USER_OPTIONS) at the beginning of the command line. So shouldn't be the same for the link/link.dll rules too ? Or, if it's at the right place, how shall people like use pass correctly arguments like -Wl,--as-needed that some distros define by default (for example Fedora) in their build system ?
Looking a bit in the history, it seems 20 years ago it was moved at the end on purpose: d636a71 Is it time to "revert" this ?
Make sure you completed the following tasks
Environment and version details
Brief problem description
In boost recently there was some modular work. One of the nasty consequences of this is that now there are more dependencies in the generated libboost_XXX.so, more than before, and actually more than necessary. See for example these cases:
Technically, this is a boost issue, to be fixed in each boost library. Yet, I was trying to workaround it globally in an easy way, by using the linker flag
--as-neededwhich would fix issues in most cases. I tried passing this argument as part of the b2linkflagsbut...-Wl,--as-neededis passed at the end of the command line. Indeed, looking here:https://github.com/bfgroup/b2/blob/c803de9a3d704a89bfc43831f8c198bf0078c007/src/tools/gcc.jam#L1068C292-L1068C318
We seem to pass
$(OPTIONS) $(USER_OPTIONS)at the end.-Wl,--as-neededis an argument whose position on the command line matters: if passed at the end, it affects only the "implicit" libraries the linker will add automatically (things like-lstdc++,-lgccor-lc). Looking at the equivalent C/CXXFLAGS for the compile command lines, we seem to pass$(OPTIONS) $(USER_OPTIONS)at the beginning of the command line. So shouldn't be the same for thelink/link.dllrules too ? Or, if it's at the right place, how shall people like use pass correctly arguments like-Wl,--as-neededthat some distros define by default (for example Fedora) in their build system ?Looking a bit in the history, it seems 20 years ago it was moved at the end on purpose: d636a71 Is it time to "revert" this ?