[bbv2] install target. Differences between bbv1 and bbv2
I just tried a install of bbv1 and bbv2 on win2k using the mingw toolset. The cmd line for bbv1 was: bjam -s"TOOLS=mingw-3_4_2" install for bbv2: bjam --v2 toolset=gcc-mgw3.4.2 install (For bbv2 I put in user.config.jam: using gcc : mgw3.4.2 : C:\Mingw\bin\g++.exe ; ) I found the following differences: 1) Default install in bbv1 goes to C:\Boost in bbv2 to C:\install 2) Generated libraries and naming is different: E.g. for thread lib: bbv1: 269KB boost_thread-mgw34-mt.lib 269KB boost_thread-mgw34-mt-1_34.lib 337KB boost_thread-mgw34-mt-1_34.dll 823KB boost_thread-mgw34-mt-d.lib 823KB boost_thread-mgw34-mt-d-1_34.lib 4.905KB boost_thread-mgw34-mt-d-1_34.dll 197KB libboost_thread-mgw34-mt.lib 197KB libboost_thread-mgw34-mt-1_34.lib 9.258KB libboost_thread-mgw34-mt-d.lib 9.258KB libboost_thread-mgw34-mt-d-1_34.lib 197KB libboost_thread-mgw34-mt-s.lib 197KB libboost_thread-mgw34-mt-s-1_34.lib 9.258KB libboost_thread-mgw34-mt-sd.lib 9.258KB libboost_thread-mgw34-mt-sd-1_34.lib bbv2: 346KB boost_thread-gcc-mt-1_34.dll 4.901KB boost_thread-gcc-mt-gd-1_34.dll 346KB boost_thread-gcc-mt-s-1_34.dll 4.901KB boost_thread-gcc-mt-sgd-1_34.dll I also tried to use the lib files of bbv2. They indeed work without having an import lib available. (No import lib might be a problem when trying to link from MSVC. But then, since the name mangling is different this might not be an issue, since one wouldn't need to do this anyways.) In bbv1 there is also an unversioned copy of the import and static libs generated, while in bbv2 there is none. The compiler tag is different: gcc vs. mgw34. No static libs for bbv2 (this might be due to a wrong thread Jamfile.v2, I'll check this.) Static libs are only generated for: prg_exec_monitor, test_exec_monitor and unit_test_framework. Also they end in *.a instead of the expected *.lib. (But this might still be corrct.) e.g: libboost_unit_test_framework-gcc-mt-1_34.a I'd like to raise the question if library tagging and set of generated libraries indeed should be allowed to be so different between bbv1 and bbv2. I also doubt that gcc name is sufficient without a version and platform (cygwin / mingw). Roland
Roland Schwarz wrote:
I just tried a install of bbv1 and bbv2 on win2k using the mingw toolset.
Thanks Roland for doing this testing... I have a few new TODOs now :-)
(For bbv2 I put in user.config.jam: using gcc : mgw3.4.2 : C:\Mingw\bin\g++.exe ; )
This is the cause of not getting the version number on the generated libs. To get the toolset version into the tag the version number has to be first. For example, for STLport+MinGW I have: using gcc : 3.4.5~mingw~stlport51 : C:/MinGW/bin/g++.exe ;
I also tried to use the lib files of bbv2. They indeed work without having an import lib available. (No import lib might be a problem when trying to link from MSVC. But then, since the name mangling is different this might not be an issue, since one wouldn't need to do this anyways.)
Yea, the MinGW linker is smart enough to auto generate the import lib directly from the DLL :-) Oh, how I wish for the day when Microsoft tools are that user friendly.
Static libs are only generated for: prg_exec_monitor, test_exec_monitor and unit_test_framework. Also they end in *.a instead of the expected *.lib. (But this might still be corrct.) e.g: libboost_unit_test_framework-gcc-mt-1_34.a
Hm, if I remember correctly from when I researched what libs work with MinGW, it can handle the *.a variants. It searches for a large variety of library names when the "-lsomelib" is specified to try and find it. Although I chose *.lib names in BBv1 because that was consistent to how the other Windows toolsets work.
I'd like to raise the question if library tagging and set of generated libraries indeed should be allowed to be so different between bbv1 and bbv2.
I'd say no they should not differ as much as possible. The larger the difference, the more pain we inflict on users who have to change their builds to accommodate new names.
I also doubt that gcc name is sufficient without a version and platform (cygwin / mingw).
I don't doubt it, I'm certain it's insufficient :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
This is the cause of not getting the version number on the generated libs. To get the toolset version into the tag the version number has to be first. For example, for STLport+MinGW I have:
using gcc : 3.4.5~mingw~stlport51 : C:/MinGW/bin/g++.exe ;
Ok, now I get e.g: libboost_thread-gcc34-mt-d-1_34.a But there still is no notion about mingw beeing used. Are they really compatible? Roland
Roland Schwarz wrote:
Rene Rivera wrote:
This is the cause of not getting the version number on the generated libs. To get the toolset version into the tag the version number has to be first. For example, for STLport+MinGW I have:
using gcc : 3.4.5~mingw~stlport51 : C:/MinGW/bin/g++.exe ;
Ok, now I get e.g: libboost_thread-gcc34-mt-d-1_34.a
But there still is no notion about mingw beeing used. Are they really compatible?
No, they are not compatible... I just checked in some changes that restore the "mgw" tag. It is also possible now to just have: using gcc : : c:/mingw/bin/g++.exe ; In the user-config and it will figure out the version and flavor automatically. Please test again :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Roland Schwarz wrote:
I found the following differences:
1) Default install in bbv1 goes to C:\Boost in bbv2 to C:\install
That should be fixed now. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
participants (2)
-
Rene Rivera -
Roland Schwarz