Mingw: build, install, .LIB files and boost-config?
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 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? 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. 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? Can I suggest that for MinGW, a native shell script, with file paths constructed relative to the boost-config path, would probably be the best way, rather than pkg-config, which is not available in MinGW/MSYS by default. Feel free to direct me to the online documentation of this stuff if it exists -- I couldn't find it though. Cheers JP -- John Pye Dept of Engineering Australian National University http://pye.dyndns.org/
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.
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'
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)
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? - Volodya
On Fri, Jan 29, 2010 at 12:06 PM, Vladimir Prus
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.
You do not really need MSYS for building Boost with MinGW, provided gcc (and not Visual Studio) is available in you path. Bootstrap will then automatically build a bjam.exe for you. If not, you can always build it manually (call "build.bat gcc" in tools\jam\src and then use the resulting bjam.exe in tools\jam\src\bin.ntx86).
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'
I fully agree with bjam --help. It provides all the information you need. As an additional example: When I build my Boost-version (a shared, debug one with MinGW), I simply call bjam as follows: bjam "--build-dir=C:\Development\Temp\Boost-install\Boost_build_1.41\Shared_Debug" "--prefix=C:\Development\Boost-install\install\Boost_1.41\Shared_Debug" "--layout=versioned" "link=shared" "variant=debug" "toolset=gcc" "threading=multi" "runtime-link=shared" install Note the --build-dir ánd the --prefix commands, specifying respectively the locations of the intermediate object-files and the final installation-files. The options link, variant, toolset, threading and runtime specify that I want a very specific build of Boost, but I can imagine that you want something else.
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)
The result of the previous bjam install is a Boost-install-dir with a lib-directory containing .lib and .dll files and an include-directory containing the .h files. I do nót need to rename those .lib files to .a files with MinGW, but perhaps because I use CMake for building my own projects. A "find_package( Boost )" with a predefined "BOOST_ROOT" variable is sufficient to find all the libraries that I need.
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?
- Volodya
I think the find_boost.cmake in CMake comes close to such a script.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
John Pye wrote:
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?
The .a suffix will be used for <toolset>gcc <target-os>windows, which corresponds to mingw. For cygwin, the current SVN HEAD still uses .lib extension.
For earlier releases, it's OK to just rename the .LIB files?
Yes.
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
The question is why is this any better than saying 'thou shalt link to -lboost_serialization'? Boost 1.41 uses system naming by default on Unix, and earlier versions of Boost will not have 'boost-config' anyway.
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.
I'm afraid the devil hides in the word "like". Nobody, up to now, was able to come up with complete specification. And, the only thing that will be immediately helped by pkg-config/boost-config solution is the filesystem->system dependency (and that only for static linking) - Volodya
participants (3)
-
André Prins -
John Pye -
Vladimir Prus