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

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
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2