From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-27 08:30:43
On Friday 24 June 2005 20:26, Mat Marcus wrote:
> > 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.
So, you'd like to have a property that disables encoding of version?
> 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
It's possible to teach V2 that static libraries have .o extension and modify
the "archive" action to use "ld -r". Just using
"type.set-generated-target-suffix" should work. I don't even think that will
break anything. I am not very happy about such tricks -- making .o files into
something strange, and I also expect some troubles because earlier versions
of darwin tools did not support "ld -r" and now it's not only possible by
recommended way. Optimally, the same "ar" command would silently start to
produce new format files. However, I doubt that Apple will care much about
compatibility for build systems.
> 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 think this is fine. But why do you need "composite"?
Also, am I right that you pass the same -isysroot in both cases? Then, why
> I will also (locally) add support for the
> MACOSX_DEPLOYMENT_TARGET variable following your suggestion from another
Great. Please feel free to ask any questions as you move along.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk