date_time broken on intel-win32-8.0
http://tinyurl.com/4y6tx LINK : fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-gd-1_32.lib' Has anybody an idea where to search? Stefan
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-gd-1_32.lib'
Has anybody an idea where to search?
OK, here's the problem: originally we had one Intel toolset: "intel-win32" which created the library suffix "iw" (note no version number!), and this is what the auto-link header currently searches for. However people have started adding versioned Intel toolsets, which means that we now produce an ad-hoc mixture of library names, some with compiler-version suffixes and some without, the autolink code could handle either form, but as it's not psychic it can't handle both :-( So, one fix is to define BOOST_ALL_NO_LIB to disable auto-linking for versioned Intel toolsets. But we really aught to come up with a better solution (if there is one). John.
John Maddock wrote:
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-gd-1_32.lib'
Has anybody an idea where to search?
OK, here's the problem: originally we had one Intel toolset: "intel-win32" which created the library suffix "iw" (note no version number!), and this is what the auto-link header currently searches for.
However people have started adding versioned Intel toolsets, which means that we now produce an ad-hoc mixture of library names, some with compiler-version suffixes and some without, the autolink code could handle either form, but as it's not psychic it can't handle both :-(
So, one fix is to define BOOST_ALL_NO_LIB to disable auto-linking for versioned Intel toolsets. But we really aught to come up with a better solution (if there is one).
:-) Well the only immediate way I can think of handling this is to add a define in the versioned toolsets that the auto-link can use as a flag to include, or not, a version with the toolset. For example in the intel-win32-8.0-tools.jam we could add: flags intel-win32-8.0 CFLAGS : -DBOOST_VERSIONED_TOOLSET=1 ; ** of course picking a good name would be nice ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Well the only immediate way I can think of handling this is to add a define in the versioned toolsets that the auto-link can use as a flag to include, or not, a version with the toolset.
For example in the intel-win32-8.0-tools.jam we could add:
flags intel-win32-8.0 CFLAGS : -DBOOST_VERSIONED_TOOLSET=1 ;
** of course picking a good name would be nice ;-)
Hey, that really could be the solution, could the define be added in the code that actually adds the version number, so it's all automatic? Oh, hold on though, when the user comes to use the compiled libraries, and builds using their IDE, it all breaks down doesn't it? John.
Stefan Slapeta wrote:
John Maddock wrote:
So, one fix is to define BOOST_ALL_NO_LIB to disable auto-linking for versioned Intel toolsets.
Where is the best place to do this? Shall I step back to the old toolset?
WARNING: I haven't tested this... but you get the idea: =================================================================== RCS file: /cvsroot/boost/boost/libs/date_time/test/Jamfile,v retrieving revision 1.20 diff -u -r1.20 Jamfile --- Jamfile 4 Aug 2004 22:29:08 -0000 1.20 +++ Jamfile 13 Aug 2004 12:47:07 -0000 @@ -8,8 +8,8 @@ # Make tests run by default. DEPENDS all : test ; -local DATE_TIME_DYNAMIC_PROPERTIES = <define>BOOST_ALL_DYN_LINK <runtime-link>dynamic <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG ; -local DATE_TIME_PROPERTIES = <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG <define>BOOST_DATE_TIME_STATIC_LINK std::locale-support ; +local DATE_TIME_DYNAMIC_PROPERTIES = <define>BOOST_ALL_DYN_LINK <runtime-link>dynamic <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG <define>BOOST_ALL_NO_LIB ; +local DATE_TIME_PROPERTIES = <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG <define>BOOST_DATE_TIME_STATIC_LINK std::locale-support <define>BOOST_ALL_NO_LIB ; =================================================================== -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (3)
-
John Maddock -
Rene Rivera -
Stefan Slapeta