From: John Pye (john.pye_at_[hidden])
Date: 2007-05-10 21:16:20
Rene Rivera wrote:
> John Pye wrote:
>
>> Rene Rivera wrote:
>>
>>> John Pye wrote:
>>>
>>> Where did it install them to? And where did you expect them?
>>>
>> I just assumed that because I was specifying MinGW, it would install the
>> files in the MinGW file tree. My assumption was wrong: If I want that I
>> have to specify --prefix=c:\MinGW, it seems.
>>
>
> Yep :-) The default build and install behavior on Windows is designed to
> mostly follow the Unix behavior. The one exception is the top level
> install location. Since there is no *standard* system location it
> installs to a recognizable location.
>
I found some files here without the special -mgw-.... stuff:
c:\Boost\bin\boost\libs\serialisation\build
Are they temp files? Should I use them? Or are they precompiled MSVC
files or something?
>
>> The files were installed to c:\Boost, but again this was a little
>> not-as-expected: it installs to c:\Boost\include\boost-1_33_1\boost. Why
>> not just to c:\Boost\include\boost ? I guess this is so that you can
>> have multiple versions present?
>>
>
> Yes that's the reason.
>
>
>> But in that case wouldn't it be neater
>> to use c:\Boost1331, c:\Boost114 or whatever, similar to Python?
>>
>
> Perhaps. But then it would mean changing the install structure across
> platforms. Which means more documentation.
>
I guess so. Or perhaps one more build option like
--suppress-versioned-subdirs?
I'd note that the typical user experience coming from Linux is that
there are no such versioned subdirectories. The files are just straight
there in /usr/lib and /usr/include.
Or perhaps such machinations are the job of someone who takes it upon
themselves to produce a special MinGW binary installer for Boost.
>
>> Perhaps it would be good if there were (a) a binary installer for MinGW
>> users.
>>
>
> Sure, and we welcome others in making such packages available.
>
I will put it on my list of would-like-to-do tasks.
>
>> Would presumably be bound to a specific version of GCC, but
>> otherwise portable?
>>
>
> It would be bound to the version of MinGW which means more than just the
> version of GCC. In particular it would be bound to the versions of any
> libraries and headers that Boost uses.
>
>
>>>> Please let me know if I'm missing something, or if there is a better way
>>>> to get started with Boost under MinGW/MSYS.
>>>>
>>>>
>>> Is there something is specific that isn't working for you? Any errors?
>>> Did you add the "c:\Boost\lib" dir to your library search path?
>>>
>>>
>> The specific problem I'm having now is that the libraries don't work for
>> me. Here is a snippet from my SCons output:
>>
>> scons: Configure: Checking for
>> Boost libraries...
>> .sconf_temp\conftest_6.cpp <-
>> |
>> |#include <sstream>
>> |#include <boost/archive/text_oarchive.hpp>
>> |#include <boost/archive/text_iarchive.hpp>
>> |
>> |int main(void){
>> | std::stringstream ss;
>> | int x1=1;
>> | const int &x = x1;
>> | boost::archive::text_oarchive oa(ss);
>> | oa & x;
>> | return 0;
>> |}
>> |
>> g++ -o .sconf_temp\conftest_6.o -c -g -Wall -IC:\mingw\include
>> -IC:\Boost\include\boost-1_33_1 .sconf_temp\conftest_6.cpp
>> g++ -o .sconf_temp\conftest_6.exe .sconf_temp\conftest_6.o
>> -LC:\mingw\lib -LC:\Boost\lib -lcppunit -lgcov -lgsl -lgslcblas -lm
>> -lboost_serialization
>> c:\MinGW\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
>> cannot find -lboost_serialization
>> collect2: ld returned 1 exit status
>> scons: Configure: no
>>
>> Perhaps I am supposed to add -mgw to my library name? That seems like a
>> strange design choice? What I am doing wrong?
>>
>
> I don't know what Scons may be doing in addition to just adding the -l
> option. But yes, you need to specify the a specific variant of the
> libraries built.
OK, so I added stuff for the correct extra library name stuff, namely
-mgw-mt-d-1_33_1, and it worked.
I note that I also needed to set my PATH to include c:\Boost\lib.
> The getting started guide has a section describing the
> names of libraries generated. As for the design choice... It's a
> requirement as many options in compiling C++ programs changes the ABI
> and code compatibility.
>
I think that something that would make things a lot easier for MinGW
users with Boost would be the provision of a shell script a la
"pkg-config". Such scripts are used with a lot of more complex libraries
in Linux, as well as GTK on Windows. Something like the following:
If I typed:
boost-config serialisation --cppflags
it would output
"-Ic:\Boost\include\boost-1_33_1"
and if I typed
boost-config --tools=mingw serialisation --libs
it would output
"-Lc:\Boost\libs" "-lboost_serialisation-mgw-mt-d-1_33_1"
This would be particularly useful in the case of GNU Makefiles and SCons
files. In the case of GNU Make, one can then have
CPPFLAGS=`boost-config --cppflags serialisation`
LDFLAGS=`boost-config --libs serialisation`
and in the case of SCons
env.ParseConfig("boost-config --libs --cppflags serialisation")
and the correct flags, with all the bells and whistles, would be added
to the environment.
This 'boost-config' file would need to be prepared at build-time and
would be installed in c:\MinGW\bin or some other path that would be
defined by build-time options.
Again I note that GTK+ uses this technique to help users set the
necessary compiler flags on Windows as well as Linux.
Cheers
JP