re: Darwin BBv2 CVS library suffix bug

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-06-16 12:59:29

>> On 6/15/05, Vladimir Prus <ghost_at_[hidden]> wrote:
>> > On Monday 13 June 2005 23:43, JOAQUIN LOPEZ MU?Z wrote:
>> > > For the record, the same thing happens with BB2 in vacpp.
>> > > For instance, serialization builds into:
>> > > 
>> > > boost_serialization-xlc-d-1_33.so.1.33.0
>> > 

[snip]

> The first question is: are those suffixes necessary for OSX in any
> case? For Linux, the suffixes allow several versions of boost to
> coexist. If OSX is the same, then we need suffixes at least for
> Boost "standalone" install. If not, and OSX has some other
> mechanism to handle library versions, we can remove the suffix
> completely.

Under the hood, OSX is built on top of BSD unix (with some NeXT-isms
thrown in). I expect that it behaves substantially the same as Linux
in this regard. At the same time, many OSX developers will be using
the XCode integrated development environment, especially now that
Apple is switching to Intel. Many commercial developers will be
moving from Codewarrior to XCode. These developers are not
comfortable with makefiles and command line environments. XCode
offers them the visual development experience that they desire. The
current version XCode use gcc 4 for its compiler, but uses its own
project format instead of makefiles. So just to be clear, to the
best of my understanding it is XCode, not OSX/darwin/gcc that
disallows libraries from ending in 1.33.0--static libs must end in .a
and shared libs in .dylib .

> If the suffix cannot be removed in all cases, we need to remove it
> selectively for your project. The problem is that boost Jamfiles
> use command line option to select if the suffix is added or not.
> Building with
> 
> bjam --layout=system
> 
> should get rid of the suffix, but it's clearly not nice solution.

It's good to know about this, thanks. But as you indicate, it may not
help much with adoption in this environment.

> Probably, we should be adding the suffix only when building Boost
> itself for install (that is via "bjam stage" or "bjam install" in
> Boost root), and not in any other case?

This sounds promising. Life for OSX boost users may also be
complicated by the new "Universal" binary format. That is, developers
will need to produce applications that will run on both Intel and PPC
macs. So a boost install could involve building and installing both
Intel and PowerPC versions of the libraries. For shared libraries, I
believe that these can be bundled together in a OSX/darwin-specific
entity known as a framework. I'll save this and other
platform-specific
details for another post.

Thanks for your response,
Mat