Re: [Boost-users] [Boost.Test] Linker chooses “wrong” main function

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code thusly:

Richard writes:

...

What boost.test does is define a main() function depending on how it is compiled. In my projects, I have a main.cpp that looks like this:

#define BOOST_TEST_MAIN #include

and this provides the canned implementation of main().

I didn't know/use this macro, but my code has BOOST_TEST_MODULE, which apparently achieves the same thing.

In both these cases it only provides an implementation of main() if dynamic linking to the test library is used: http://www.boost.org/doc/libs/1_50_0/libs/test/doc/html/utf/compilation.html...

Actually, I did say that I am using static linking, I guess I was not clear enough.

Sorry, I missed that. When you said you switched to static linking, I thought you were only referring to 3rd party libraries like libpng.

I didn't actually specify *any *boost libs, as these are (somehow) linked automatically (on VS2010, probably with some #pragma calls).

Yes.

Perhaps this gets done *after* the rest of the explicitly stated libs.

http://msdn.microsoft.com/en-us/library/7f0aews7.aspx says that #pragma comment(lib, "xxx") places a search record entry for xxx at the end of the default search record entries.

Is there a way to get the correct libs to properly and automatically link before any other libs?

It would be better to identify where your errant main() is coming from and prune it at the source.

Is there some MACRO or other way to get the name of the correct libraries so that I don't need to explicitly state it for each boost version?

I'm not aware of anything, but look at the above URL for the #pragma and check the mentioned command-line arguments.

Here's the begining CMakeLists.txt file:

project(${PNG_LIBRARY}) # List of C++ files: ocv_include_directories("${CMAKE_CURRENT_SOURCE_DIR}" ${ZLIB_INCLUDE_DIR}) file(GLOB lib_srcs *.c) file(GLOB lib_hdrs *.h)

Ugh. PNG already has it's own build logic that handles everything properly; there was no need for OpenCV to go reinvent the libpng build logic. But hey, some people insist on reinventing the wheel because *theirs* is rounder. I'd make a patch to OpenCV that fixes their globby-ness and submit it back to them. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com