Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-21 13:41:41

From: "Daniel Lidström" <daniel.lidstrom_at_[hidden]>

> >Oh. I build Cygwin libraries all the time with the .lib suffix; it works
> >just fine.
> Where is the logic in that??? cygwin libraries are built using gcc so the
> output files should be .a and .so files, anything else is not expected,
> since cygwin is a kind of unix clone.

We all know what's expected, however a primary design criterion for
Boost.Build was to be able to issue one bjam invocation that builds for
multiple compilers (e.g. GCC/MSVC/Intel). Switching platform conventions
midstream wasn't something that was easy to account for.

> >The key with bjam is not to try to build bjam itself under Cygwin. Just
> >the regular Win32 build from the Boost website. We've tried to get the
> >Cygwin build of bjam to work a couple of times, but there are problems
> >nobody's had time to diagnose them.
> I am using the bjam from the boost website. What has this got to do with
> question anyway?

It seemed like you might have been having a problem caused by using a
Cygwin build of bjam; that's all.

> > If you insist on .a files, you could try setting SUFLIB=.a, either in
> >your environment:
> >
> > bash> export SUFLIB=.a
> >
> > or on the bjam command-line:
> >
> > bash> bjam -sSUFLIB=.a ...
> Are you saying that .lib files produced by visual c++ have the same
> as library files produced by gcc under cygwin?

No. What did I say to indicate that?

> When I compiled the threads library I specified sTOOLS=gcc, yet it
> .lib files. Is that the behaviour under linux, solaris, etc, as well?

No, Boost.Build decides what extension to use for various target types
based on the host OS. Cygwin is an oddball exception which (mostly) uses
unix conventions on NT. Note that executables still end with .exe ;-).

           David Abrahams * Boost Consulting
dave_at_[hidden] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at