#14585: Boost 1.34.1: provide alternate name to boost_unit_test_framework.a for static linking w/ built-in main() --------------------------------+------------------------------------------- Reporter: ods94043@yahoo.com | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Keywords: | --------------------------------+------------------------------------------- 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... -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/14585> MacPorts </projects/macports> Ports system for Mac OS