Re: [Boost-users] Mingw: build, install, .LIB files and boost-config?

Subject: Re: [Boost-users] Mingw: build, install, .LIB files and boost-config?
From: John Pye (john.pye_at_[hidden])
Date: 2010-01-29 20:38:13

Vladimir Prus wrote:
> John Pye wrote:
>
>   
>> Hi all
>>
>> While I'm aware that MinGW is not one of the 'primary' platforms for
>> MinGW, I wanted to ask a few questions to help me in the task of
>> building a binary copy of Boost for this platform that's as good as it
>> can be.
>>
>> Firstly, what would be the correct build commands to build Boost for
>> MinGW such that I end up with both shared libraries and static
>> libraries? What I've worked out so far is shown here:
>> http://ascendwiki.cheme.cmu.edu/Binary_installer_for_Boost_on_MinGW
>>     
>
> The expected commands are:
>
> 	./bootstrap.sh
> 	./bjam
>
> assuming that you use msys shell, bootstrap.bat in cmd.exe shell. This is
> for 1.41.
>   

OK, thanks.

>> Secondly, to install Boost at an arbitrary path under MinGW, what is the
>> correct BJAM command? On MinGW, I'm not running ./configure, so the
>> suggestions from the Unix build documentation don't make sense. By
>> default under MinGW, if I run "bjam install", my files end up in
>> c:\Boost but I'd like too have another target directory, so that it's
>> possible to build even without write privileges to that folder. Is there
>> such a thing as "bjam --install-prefix=c:/MinGW install"? Is there a way
>> to strip out all the redundant folder levels like "release" and
>> "gcc-mingw-3.4.5" etc?
>>     
>
> Uhm, 'configure'? I suggest you use current Boost, like 1.41, that does not
> have that thing at all. Anyway, the answer to your question is inside
> the output of 'bjam --help'
>   

Sorry, yes, I meant 'bootstrap.sh'.

>   
>> Third, using BJAM on MinGW results in .LIB files being generated. These
>> .LIB files are NOT correctly names for use with MinGW. As far as I can
>> tell, I have to rename them as .A files, or else do something else with
>> them so that they'll correctly be detected by the the GCC "-l" linker flag.
>>     
>
> Please use SVN HEAD (or 1.42 beta)
>   

So I understand that the .a suffix will be correctly implemented for 
Cygwin and MinGW/MSYS for 1.42.0?

For earlier releases, it's OK to just rename the .LIB files?

>> Finally, there was a bit of discussion on the mailing list about a year
>> ago about providing a "boost-config" script. With the ever-changing
>> naming conventions for Boost libs, and the possible presence of static
>> libraries, shared libraries, -mt, -d, and other file suffixes, such a
>> script would be INVALUABLE for people looking to access pre-built Boost
>> binaries for their projects. It would be an almost trivial task to
>> implement such a script -- has there been any progress on this anywhere?
>>     
>
> I am afraid nobody has ever provided a *specification* for such a script.
> Presumably, because it's less trivial than originally though. Can you provide
> a spec?
>   

There are countless examples of these scripts, but there's not a 
universal standard for them, nor does there need to be. The key thing is 
that there should be a clear "--help" output from the script that shows 
what possible information can be retrieved. Typical usage and outputs

$ boost-config --cppflags
-I/opt/boost/include

In the case of Boost, there are actually many libraries, rather than 
just one, so the usage of "--libs" would perhaps have to be something like

$ boost-config --libs=serialization,graph
-L/opt/boost/lib -lboost_serialization-mt -lboost_graph-mt

The extra library suffixes etc are things that vary from build to build 
and machine to machine, so the script saves everyone a lot of messing 
around by returning those things according to the local install.

The above pretty much summarises the basic functionality. The same input 
on a different system could result in different output, eg for static 
libraries Boost:

$ boost-config --libs=serialization,graph
/opt/boost/lib/libboost_serialization-mt.a 
/opt/boost/lib/libboost_serialization-mt.a

One might thing about some additional flags that switch to linking 
against 'debug' builds of the libraries, instead of the default release 
versions.

Once the script is written, it's very simple to build a cross-platform 
makefile to link against Boost, for example

CPPFLAGS = `boost-config --cppflags
LINKFLAGS = `boost-config --libs=serialization`

prog: myprog.cpp
   $(CXX) $(CPPFLAGS) -o prog myprog.cpp $(LINKFLAGS)

Something like that, anyway. Because the boost-config script looks after 
the platform-specific stuff, all the downstream building and linking 
becomes much simpler.

Cheers
JP