Boost's automatic selection of debug vs release libaries on link - how to disable?
Hello everyone, I've noticed that when linking Boost libraries, the linker implicitly knows whether it requires a debug or a release Boost library, and what the full name of the library is. E.g. on Windows the linker wants "boost_serialization-vc80-mt-d-1_37.lib" in debug and "boost_serialization-vc80-mt-1_37.lib" in release. I'm working in an SCons build system where SCons runs the show and the Boost libraries will be custom-renamed and the linker told specifically what libraries to link. Is there any way to disable this implicit naming feature in the bjam build step through a compiler option? Damien
Damien Hocking wrote:
Hello everyone,
I've noticed that when linking Boost libraries, the linker implicitly knows whether it requires a debug or a release Boost library, and what the full name of the library is. E.g. on Windows the linker wants "boost_serialization-vc80-mt-d-1_37.lib" in debug and "boost_serialization-vc80-mt-1_37.lib" in release.
I'm working in an SCons build system where SCons runs the show and the Boost libraries will be custom-renamed and the linker told specifically what libraries to link. Is there any way to disable this implicit naming feature in the bjam build step through a compiler option?
- There's no "bjam build step", the official build system used by C++ Boost is called Boost.Build - The autolink behaviour is not controlled by Boost.Build, it is controlled by MS-specific #pragmas that occur (indirectly) in the headers of affected libraries - You can disable autolink by defining BOOST_ALL_NO_LIB macro when building the application that uses C++ Boost libraries. - Volodya
Thanks Vlad, That's what I needed. I should have been clearer about bjam. Damien _____ From: Vladimir Prus [mailto:vladimir@codesourcery.com] To: boost-users@lists.boost.org Sent: Sun, 15 Feb 2009 00:45:50 -0700 Subject: Re: [Boost-users] Boost's automatic selection of debug vs release libaries on link - how to disable? Damien Hocking wrote:
Hello everyone,
I've noticed that when linking Boost libraries, the linker implicitly knows whether it requires a debug or a release Boost library, and what the full name of the library is. E.g. on Windows the linker wants "boost_serialization-vc80-mt-d-1_37.lib" in debug and "boost_serialization-vc80-mt-1_37.lib" in release.
I'm working in an SCons build system where SCons runs the show and the Boost libraries will be custom-renamed and the linker told specifically what libraries to link. Is there any way to disable this implicit naming feature in the bjam build step through a compiler option?
- There's no "bjam build step", the official build system used by C++ Boost is called Boost.Build - The autolink behaviour is not controlled by Boost.Build, it is controlled by MS-specific #pragmas that occur (indirectly) in the headers of affected libraries - You can disable autolink by defining BOOST_ALL_NO_LIB macro when building the application that uses C++ Boost libraries. - Volodya _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi There is a problem with the 1.38 release of Boost that is preventing me from compiling using gcc on a mac some code that compiled correctly in previous releases. I now get lots of 'multiply defined' error messages when certain boost header files are included in specific ways, e.g. /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol boost::test_tools::(anonymous namespace)::check_is_close bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/BiobaseLexer. o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common) bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/ArrayLexer.o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common) I have attached minimal example which seems to reproduce the problem. It seems to be associated with the change that was introduced in svn release r49800. (https://svn.boost.org/trac/boost/changeset?new=49800%40trunk&old=49793% 40trunk) I have run bjam -n -a with and without r49800 and also bjam with and without the r49800 change, which appears to show that the problem arises after the change has been introduced: The results are also included in the tar.gz file Nigel Dyer
Dyer, Nigel wrote:
Hi
There is a problem with the 1.38 release of Boost that is preventing me from compiling using gcc on a mac some code that compiled correctly in previous releases. I now get lots of 'multiply defined' error messages when certain boost header files are included in specific ways, e.g.
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol boost::test_tools::(anonymous namespace)::check_is_close bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/BiobaseLexer. o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common) bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/ArrayLexer.o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common)
I have attached minimal example which seems to reproduce the problem.
It seems to be associated with the change that was introduced in svn release r49800. (https://svn.boost.org/trac/boost/changeset?new=49800%40trunk&old=49793% 40trunk)
I have run bjam -n -a with and without r49800 and also bjam with and without the r49800 change, which appears to show that the problem arises after the change has been introduced:
Hi Nigel, thanks for a comprehensive bug report. On the first look, it appears that Boost.Build change is actually right -- it fixes a previously introduced bug that made PCHs non-functional. And, then, it appears that including boost.test in PCH somehow upsets the compiler. Do things improve if you take all boost.test headers out of bio-pch.h? Thanks, Volodya P.S. Please don't ask new questions by replying to unrelated email, I've nearly missed this one.
Hi Nigel ! On Sunday 22 February 2009, Vladimir Prus wrote:
Dyer, Nigel wrote:
Hi
There is a problem with the 1.38 release of Boost that is preventing me from compiling using gcc on a mac some code that compiled correctly in previous releases. I now get lots of 'multiply defined' error messages when certain boost header files are included in specific ways, e.g.
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol boost::test_tools::(anonymous namespace)::check_is_close bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/BiobaseL exer. o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common) bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/ArrayLex er.o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common)
That looks like #2390 again. https://svn.boost.org/trac/boost/ticket/2390 Can you apply http://svn.boost.org/trac/boost/changeset/49865 and maybe http://svn.boost.org/trac/boost/changeset/50388 and see if this fixes the issue ?
thanks for a comprehensive bug report. On the first look, it appears that Boost.Build change is actually right -- it fixes a previously introduced bug that made PCHs non-functional. And, then, it appears that including boost.test in PCH somehow upsets the compiler. Do things improve if you take all boost.test headers out of bio-pch.h?
It cleanly compiles with gcc-4.3.2 on Linux. Strange.
P.S. Please don't ask new questions by replying to unrelated email, I've nearly missed this one.
Yes :-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Hi Volodya The two boost libraries that cause problems are boost/test and boost/lambda, and if I remove them all is fine in this example. The problem only appears with <link>static. If there is no <link>static requirement then I get an error message saying that the bio-pch.h.gch is not used because BOOST_SYSTEM_DYN_LINK us defined. I assume that this means that precompiled headers are incompatible with dynamic link builds, although this does not appear to be mentioned. If I define the exe as below in a static build the precompiled header builds with no problems and the code links with no errors. I suspect that by not having the pch as a source this means it is not working as a pch however exe nigel : Lexer/BiobaseLexer.cpp Lexer/ArrayLexer.cpp #/boost/filesystem//boost_filesystem main_nigel.cpp : <variant>static:<source>bio-pch <library>/boost/system//boost_system ; And apologies about the misleading header on my first posting. Nigel Dyer PhD student MOAC Doctoral Training Centre University of Warwick Coventry CV4 7AL -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 22 February 2009 09:36 To: boost-users@lists.boost.org Subject: Re: [Boost-users] 'Multiply defined' errors in Boost 1.38. Dyer, Nigel wrote:
Hi
There is a problem with the 1.38 release of Boost that is preventing me from compiling using gcc on a mac some code that compiled correctly in previous releases. I now get lots of 'multiply defined' error messages when certain boost header files are included in specific ways, e.g.
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol boost::test_tools::(anonymous namespace)::check_is_close
bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/BiobaseLexer.
o definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common)
bin/darwin-4.0.1/release/link-static/threading-multi/Lexer/ArrayLexer.o
definition of boost::test_tools::(anonymous namespace)::check_is_close in section (__DATA,__common)
I have attached minimal example which seems to reproduce the problem.
It seems to be associated with the change that was introduced in svn release r49800.
(https://svn.boost.org/trac/boost/changeset?new=49800%40trunk&old=49793%
40trunk)
I have run bjam -n -a with and without r49800 and also bjam with and without the r49800 change, which appears to show that the problem arises after the change has been introduced:
Hi Nigel, thanks for a comprehensive bug report. On the first look, it appears that Boost.Build change is actually right -- it fixes a previously introduced bug that made PCHs non-functional. And, then, it appears that including boost.test in PCH somehow upsets the compiler. Do things improve if you take all boost.test headers out of bio-pch.h? Thanks, Volodya P.S. Please don't ask new questions by replying to unrelated email, I've nearly missed this one. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dyer, Nigel wrote:
Hi Volodya
The two boost libraries that cause problems are boost/test and boost/lambda, and if I remove them all is fine in this example.
So, you have a workaround?
The problem only appears with <link>static. If there is no <link>static requirement then I get an error message saying that the bio-pch.h.gch is not used because BOOST_SYSTEM_DYN_LINK us defined.
Well, you can add <use>/boost/filesystem//boost_filesystem to the requirements of our pch target so that the PCH is built withe the same defines as the your executable.
I assume that this means that precompiled headers are incompatible with dynamic link builds, although this does not appear to be mentioned.
No, this means that PCH should be built with *exactly* the same compiler options, including defines.
If I define the exe as below in a static build the precompiled header builds with no problems and the code links with no errors. I suspect that by not having the pch as a source this means it is not working as a pch however
exe nigel : Lexer/BiobaseLexer.cpp Lexer/ArrayLexer.cpp #/boost/filesystem//boost_filesystem main_nigel.cpp : <variant>static:<source>bio-pch
There's no such variant as 'static', FWIW. There's <link>static - Volodya
Hi Volodya Apologies... I now see that the boost documentation says that the gcc compiler prior to 4.2 does not support anonymous namespaces in precompiled headers. I am using the Darwin compiler that comes with the Apple Servers, and had rather assumed it was based on a current gcc, but I see that it is still based on gcc 4.0.1. The simple workaround is to not use precompiled headers. I have also showed that the problem can be fixed by removing the boost libraries from the pre-compiled headers that use anonymous namespaces, either directly or indirectly. Your other comments were very useful, although I am still looking into why the <use>/boost/filesystem//boost_filesystem is needed in the pch definition on the mac, when it does not appear to be necessary on other platforms. I have found a number of other problems mainly relating to dependency checking that occur on the mac and not on the other platform, so I am going to install a later version of gcc, which will hopefully bring the mac server platform in line with the linux and windows platforms where everything works just fine. Nigel -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 22 February 2009 16:54 To: boost-users@lists.boost.org Subject: Re: [Boost-users] 'Multiply defined' errors in Boost 1.38. Dyer, Nigel wrote:
Hi Volodya
The two boost libraries that cause problems are boost/test and boost/lambda, and if I remove them all is fine in this example.
So, you have a workaround?
The problem only appears with <link>static. If there is no
<link>static
requirement then I get an error message saying that the bio-pch.h.gch is not used because BOOST_SYSTEM_DYN_LINK us defined.
Well, you can add <use>/boost/filesystem//boost_filesystem to the requirements of our pch target so that the PCH is built withe the same defines as the your executable.
I assume that this means that precompiled headers are incompatible with dynamic link builds, although this does not appear to be mentioned.
No, this means that PCH should be built with *exactly* the same compiler options, including defines.
If I define the exe as below in a static build the precompiled header builds with no problems and the code links with no errors. I suspect that by not having the pch as a source this means it is not working as
a
pch however
exe nigel : Lexer/BiobaseLexer.cpp Lexer/ArrayLexer.cpp #/boost/filesystem//boost_filesystem main_nigel.cpp : <variant>static:<source>bio-pch
There's no such variant as 'static', FWIW. There's <link>static - Volodya _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dyer, Nigel wrote:
Hi Volodya
Apologies... I now see that the boost documentation says that the gcc compiler prior to 4.2 does not support anonymous namespaces in precompiled headers. I am using the Darwin compiler that comes with the Apple Servers, and had rather assumed it was based on a current gcc, but I see that it is still based on gcc 4.0.1. The simple workaround is to not use precompiled headers. I have also showed that the problem can be fixed by removing the boost libraries from the pre-compiled headers that use anonymous namespaces, either directly or indirectly.
Your other comments were very useful, although I am still looking into why the <use>/boost/filesystem//boost_filesystem is needed in the pch definition on the mac, when it does not appear to be necessary on other platforms.
Nigel, in general, you always need to build PCH and the application with the same set of defines. I do not know if other compilers you have tested are less picky, or silently don't use PCH.
I have found a number of other problems mainly relating to dependency checking
In Boost.Build? I know that tracking dependency problems is not fun, but it's only possible to fix them if you come up with a remotely reproducible test case. Please make sure you are using the latest Boost.Build, e.g. nightly built package on boost.org/boost-build2 Thanks, Volodya
participants (4)
-
Damien Hocking -
Dyer, Nigel -
Juergen Hunold -
Vladimir Prus