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

Subject: Re: [Boost-users] [Boost.Test] Linker chooses “wrong” main function
From: Richard (legalize+jeeves_at_[hidden])
Date: 2012-08-29 19:31:44

[Please do not mail me a copy of your followup]

boost-users_at_[hidden] spake the secret code
<CAEWUs4jLtGbC=vL130zbat3UTMWd750AcbsA-B3s1zD7-bkS=g_at_[hidden]> thusly:

>Richard <legalize+jeeves <at> mail.xmission.com> 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 <boost/test/unit_test.hpp>
>>
>> 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#utf.flag.module>

>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>