Re: [jamboost] re: Darwin BBv2 CVS library suffix bug

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-06-24 11:26:21

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Friday, June 24, 2005 3:40 PM +0400 Vladimir Prus <ghost_at_[hidden]>
wrote:

> On Friday 17 June 2005 20:50, Mat Marcus wrote:
> 
>> >> Ok, understood.
>> > 
>> > What about libA.1.2.3.dylib?
>> 
>> It works.
> 
> After reading Apple docs, it seems that the above naming style is exactly
> the style one should use. 
> 
> Because of that, I've modified Boost's top-level Jamfile.v2 to avoid
> adding the suffix. This should fix your problem with XCode.
> 
> However, there's yet another question -- the library still includes
> version number (between library name and "dylib"). That will require
> that you update your XCode projects when Boost version change. Is that a
> problem to you?
>
> If yes, I can introduce a way to control naming style with a property (as 
> opposed to command line switch). Just say a word ;-)
> 

This is great, thanks. There are a few more issues that I ought to mention
with respect to libraries on Mac OS X.

It seems that Apple has broken ar(1) with respect in the case of "fat" .o's
(those with code for both -arch i386 and -ar ppc). The only way that I know
to continue to use static libraries is to use libtool -static instead of ar
for the piecemeal archive rule. I changed my darwin.jam to use libtool, and
it seems to work, though I'm not sure of all the ramifications:

actions piecemeal archive
{
# ar -c -r -s $(ARFLAGS) "$(<:T)" "$(>:T)"
libtool -static -o "$(<:T)" $(ARFLAGS) "$(>:T)"
}

But even this is not exactly what Apple has been recommending. It seems
that static libs are becoming second class citizens. In particular, if an
Xcode project builds against static libraries then "fast linking" and "edit
and continue" will not work. They suggested that since .o files now have
the ability to be comprised of multiple other .o files, we could use them
instead. I'm not sure what sort of rule would accommodate this. An example
might help to clarify what I am asking. In the current world I might create
a static library foo.a from the a.o, b.o and c.o, produced from a.cpp,
b.cpp, and c.cpp respectively. Apple has suggested that we replace the
library foo.a with a super-object-file foo.o that "contains" a.o, b.o, and
c.o, using ld -r. Can such a strategy even work with bbv2, or might it be a
good idea to talk to encourage Apple to improve their static library
support?

Thanks,
Mat

P.S. Soon I will be away from email for two weeks, so please forgive me if
my replies are late.

P.P.S. The other change that I made to the darwin toolset is:

feature isysroot : : free ;

feature arch : none i386 fat : composite ; # We don't turn on
link-incompatible for now;
flags darwin.compile OPTIONS <arch>fat : -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk ;
flags darwin.compile OPTIONS <arch>i386 : -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk ;

Is this the right way to go? I will also (locally) add support for the
MACOSX_DEPLOYMENT_TARGET variable following your suggestion from another
email.

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2185)

iQA/AwUBQrw0ThIZBaoznf65EQIkSgCbBLkeP27hCbPOo+uMeGsUnUU3iYsAoIxV
Ji97dCC2pG7sOPUa1SGPvu9d
=w4Ul
-----END PGP SIGNATURE-----