Boost logo

Boost-Build :

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
> support?

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
it's needed?

> I will also (locally) add support for the
> MACOSX_DEPLOYMENT_TARGET variable following your suggestion from another
> email.

Great. Please feel free to ask any questions as you move along.

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at