Boost 1.34.1: provide alternate name to boost_unit_test_framework.a for static linking w/ built-in main()

[ods94043@…]

According to ​http://archives.free.net.ph/message/20071221.072731.44b6bcac.en.html, starting with 1.34.1, there is an important difference between the static and dynamic library versions of libboost_unit_test_framework: the built-in main() routine is defined in the static version of the library, but _not_ the dynamic one. This sets up a very awkward collision between the Boost unit test libraries currently in MacPorts and Mac applications.

The problem is that, if one wants to use the main() that Boost provides, one must find a method of explicitly specifying the static library. However, both have the same prefix (libboost_unit_test_framework.*), and the dynamic library extension appears to be tried first, and used--resulting in an "Undefined symbols: _main" linker error.

On other platforms, you could probably work around this difficulty by passing -static to the linker. However, that won't work on Mac OS X, because just about every app out there needs at least one dynamic library/object file, and -static turns off ALL of them. In my case, attempting to use -static quickly results in a "can't locate file for: -lcrt0.o" error.

The only workaround I could think of for this problem, apart from simply giving up and supplying my own main(), is to create a new name for the static library that won't be shadowed by a dynamic library with the same name; e.g. libboost_unit_test_framework-static.a -> libboost_unittest_framework-1_34_1.a. This took me a long time to figure out, though--it would be nice if users of the port didn't all have to come up with this workaround themselves. Though I'm a bit wary of asking for a workaround like this to be incorporated into the port, I think it's justified on the grounds that it's the only way I can think of to make this particular aspect of Boost compatible with the way the Mac world is set up.

Of course, if you follow this workaround, it is probably necessary to provide similar workarounds to the other varieties of unit test libraries that are provided by the Boost port.

I suppose another possibility would be to go back to the Boost folks and get them to recant their change...

[jmroot (Joshua Root)]

Cc maintainer.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Instead of using

c++ ... -L${prefix}/lib -lboost_unit_test_framework

which, as you point out, would select the dynamic library, why can't the full name be specified

c++ ... ${prefix}/lib/libboost_unit_test_framework.a

?

[sanchom (Sancho McCann)]

Yeah, that (mcalhoun's suggestion) should fix it. Does that work for you jmr?

[sanchom (Sancho McCann)]

Oops, I meant "does that work for you ods94043" ?

[ods94043@…]

Yes, this works.

I think I will follow up with the Boost folks to see if they will incorporate an addendum to their platform-specific Boost.Test documentation.

Thanks!

[sanchom (Sancho McCann)]

Request this ticket be closed.

[(none)]

Milestone Port Enhancements deleted