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

[MacPorts]

#14585: Boost 1.34.1: provide alternate name to boost_unit_test_framework.a for
static linking w/ built-in main()
--------------------------------+-------------------------------------------
 Reporter:  ods94043 at yahoo.com  |       Owner:  macports-tickets at 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