Boost C++ Libraries: Ticket #3435: Linking failure with MSVC 7.1

attachment set

Andrey Semashev — Fri, 11 Sep 2009 15:46:54 GMT

attachment → trivial_singleton.hpp.patch

The fix modifies the way singleton instance is acquired

status changed; resolution set

Gennadiy Rozental — Sun, 22 Nov 2009 22:41:18 GMT

status new → closed
resolution → worksforme

Works fine for me.

How do you build Boost.Test and your test modules?

status changed; resolution deleted

Andrey Semashev — Mon, 23 Nov 2009 05:42:47 GMT

status closed → reopened
resolution worksforme

It doesn't come to the test modules, as Boost.Test doesn't build. The problem is still present in the 1.41 release.

Here is my build script, as I run it from Cygwin bash:

	if [ ! -f tools/jam/src/bin.ntx86/bjam.exe ]
	then
		pushd ./tools/jam/src >/dev/null
		./build.bat
		popd >/dev/null
	fi
	export HAVE_ICU=1
	export ICU_PATH="$ROOT_DIR/ThirdParty/icu"
	export ICU_LINK="/LIBPATH:$ROOT_DIR/ThirdParty/icu/win32/lib icuuc.lib icuin.lib icudt.lib"
	export ZLIB_BINARY=zlib
	export ZLIB_INCLUDE=$ROOT_DIR/ThirdParty/ZLib/inc
	export ZLIB_LIBPATH=$ROOT_DIR/ThirdParty/ZLib/lib/win32
	tools/jam/src/bin.ntx86/bjam.exe -d+2 -j 2 --stagedir=stage.vc7 toolset=msvc-7.1 stdlib=stlport variant=release link=shared runtime-link=shared threading=multi optimization=speed inlining=full rtti=on exception-handling=on debug-symbols=on "cxxflags=-G7 -arch:SSE2 -Oi -GL" "linkflags=/LTCG /OPT:REF,ICF" --with-test stage

I'm using STLPort 5.1.4. The ROOT_DIR variable in the script is D:. I attached the complete build log that shows compiler flags and errors.

attachment set

Andrey Semashev — Mon, 23 Nov 2009 05:43:45 GMT

attachment → build_log.txt

Complete build for 1.41

Andrey Semashev — Mon, 23 Nov 2009 06:02:46 GMT

BTW, without STLPort the problem is still the same.

status changed; resolution set

Gennadiy Rozental — Mon, 23 Nov 2009 06:55:57 GMT

status reopened → closed
resolution → wontfix

From what I can tell the reason for the linking error is the flag /GL (You really should have found it yourself). Just skip it when you build testing framework. Not sure why you want to build optimized version of UTF in a first place.