This shoud be a simple problem for users more advanced than I am. :-)
How do I use the boost library with cygwin on windows?
I am programing with g++ using cygwin on a winxp machine.
I need modified Bessel functions of the second order, so I downloaded the latest version of the boost library and installed it in
'c:\cygwin\lib\boost_ 1_ 38_0\' folder.
I am trying to run the "example.cpp" program from the "getting started" section of their website:
http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html
I am compiling from the directory where I created the example file using a simple Bash shell command line: 'g++ -Wall example.cpp'
I keep getting the message:
"boost/lambda/lambda.hpp: no such file or directory"
I tried every possible combination of -L, -l, -I options in the command line to include the directory, to no avail. Also tried to add the folder in the PATH line of my windows system.
How do I link to the /boost directory and ALSO to all subdirectories? The header file 'lambda.hpp' is calling other header files in subdirectories.
You're probably not that familiar with C++ yet? It seems you are confusing terms.
C++ programs are built in two steps: compiling and linking. In the first step, each source file (typically called .cpp) is handled individually. Each .cpp file usually uses multiple headers, so the compiler first inserts those - literally. That's why it's called #include.
In the second step, the linker takes all the compiled .cpp files together and builds your final program. Some of those compiled .cpp's might have been bundled together before, in which the bundle is called a library.
Boost is a collection of headers and .cpp files. So, both compiler and linker might need to find the Boost directories. From your error message, it's clear that the compiler step is the problem. The linker does not need headers anymore.
The compiler will see the #include <boost/lambda/lambda.hpp> instuction. That means it needs to know where that first-level boost directory is found. I would guess at this point that the path would be /lib/boost_ 1_ 38_0/include (there's always the find / -name lambda.hpp shotgun appraoch)
If you are not utterly wedded to cygwin, you should take a look at http://nuwen.net/mingw.html which gives you a complete MinGW C++ installation with all the libraries (such as Boost) set up for you.
Edit: I should make it clear you can use this MinGW installation in addition to Cygwin, not as a replacement. Just make sure the MinGW bin directory appears in your PATH before the Cygwin one.
I think you need -I /lib/boost_1_38_0 - although that's a pretty unusual place to put it. You'll have to let us know how you installed it, did you just unzip it in the location you said, or did you run the makefiles? I assume that since you gave a windows path you didn't install it within cygwin - which you probably should do. The instructions in the getting started guide for unix should help - although don't download a prebuilt bjam - it needs to be built with cygwin.
But if you're not very familiar with cygwin (or unix in general) I think you might find it easier to use a native windows tool - as in Neil Butterworth's answer.
Thank you all for the information, it's a nice introduction to the use of libraries with cygwin.
Daniel was right. While any variation gives an error, the following line (using caps i) does the trick:
g++ -Wall -I /cygdrive/c/cygwin/lib/boost_1_38_0/ example.cpp -o example
I will also check MinGW in the next few days.
p.s. I simply downloaded and unzipped boost in that folder, but since I am only using header files I probably won't need to compile with cygwin. [The boost version included with cygwin was 1.33, which does not seem to have Bessel functions.]
This is on win7 cygwin64 g++ 5.4, and boost-1.64.7z on 2017-7. Google doesn't show any useful result for getting started for boost on windows (is boost out of fashion?).
By experimenting, I managed to compile and run a boost graph sample program as follows:
:: g++ 5.4 in c:\cygwin64
:: 7z extract boost download in c:\tools\boost\boost164
> set BOOST_ROOT=c:\tools\boost\boost164
> setx BOOST_ROOT c:\tools\boost\boost164 -m
> cd %BOOST_ROOT%
> bootstrap.sh gcc (the bat files doesn't work)
> b2.exe
...failed updating 58 targets...
...skipped 18 targets...
...updated 1123 targets...
:: Lots of example here (not ranked highly by google)
> mklink /D eg %BOOST_ROOT%/libs/graph/example
:: Compiled and run [maxflow code using boost library][1]
:: http://vision.csd.uwo.ca/code
> unzip ; vi Makefile
CPPFLAGS = -I %BOOST_ROOT%/
LDFLAGS = -L%BOOST_ROOT%/stage/lib
> make
> set PATH=%PATH%;%BOOST_ROOT%/stage/lib
> maxflow.exe
Flow = 6
Related
To distribute a Qt appication to Windows users as a simple .exe file, one would need to link statically with a static version of Qt libraries. Assume we distribute our license under an open license so that static linking of Qt is allowed. So we just need static library binaries of Qt5Core, Qt5Gui, Qt5Widgets. How to get them?
The binary distribution of Qt5 comes with dynamic libraries only. It contains some .lib files as well - but beware, these are not the static libraries, but some auxiliary files. They can be distinguished from true static libraries by their size: true static libraries are much bigger (many MB in the case of Qt5 components). So we need to statically compile Qt5 ourselves. This turns out to be surprisingly difficult.
The official instructions (http://doc.qt.io/qt-5/windows-building.html) are almost useless: Way too short, they do not even convey an idea of the difficulty of the task. A precise, up-to-date, step-by-step guide how to compile Qt5 into static libraries is currently missing. We should have it here.
The short answer: Don't waste your time on this. Link dynamically, and let an installer distribute your application. This is the only mode that is seriously supported by Qt5 and by CMake. Working without their support and against their advise is close to hopeless. Setting up an installer is far easier (though no fun either - we currenly use black magic from https://hk.saowen.com/a/d1cf90fcfea6d511629fd5a6c8113808721a7f19656677e8a5fab370a8d35cd4).
The long (yet incomplete) answer, in case you want to outsmart me:
The following steps brought me deceptively close to a solution. I succeeded in building static libraries, but I failed to link my application: Upon getting hundreds of LNK2001 and LNK2019 errors caused by cryptic unresolved external symbols, I had to give up.
So here comes a step-by-step description of what worked for me in October 2018 on a Windows10 virtual desktop. For each installation step, a check is indicated. If a check fails then fix the problem before proceeding further.
To start, install some tools that are needed later on:
Perl, needed for zlib and openssl configuration:
Skip if "perl -v" works.
Get installer from https://www.activestate.com/activeperl
Run installer -> will install to C:\Perl64.
Check: Restart terminal and try "perl -v".
An editor that can handle Unix end-of-line. Notepad won't do. Install vim, emacs, or whatsoever.
chocolatey package manager, needed to install flex and bison:
Run admin shell (Circle Menu > search for "Command" > right-click on "Command Prompt" > run as Admin)
Copy download command from https://chocolatey.org/install#install-with-cmdexe
Paste command to admin shell, and watch installation
Check: in terminal, try command "choco"
flex and bison, needed by qtbase compilation:
It's not obvious to get the right version of flex. From gnuwin32.sourceforge.net I got an outdated flex that missed a command-line argument required during Qt compilation. Compiling flex from source introduces a tail of further dependences. The simplest solution I found uses the Chocolatey package manager.
In admin shell, run: "choco install winflexbison3". This creates a directory X that contains the binaries win_flex.exe and win_bison.exe and a supporting "data" folder. Find out the location of X. In my case, X=C:\ProgramData\chocolatey\lib\winflexbison3\tools
Check: cd X, and run "win_flex --version", "win_bison --version".
During Qt compilation, these tools will be needed under their standard names "flex" and "bison". Therefore we need symbolic links flex->win_flex, bison->win_bison.
mlink X\flex.exe X\win_flex.exe
mlink X\bison.exe X\win_bison.exe
note: mklink needs absolute paths to work reliably
note: the symlink must not go to another directory lest bison won't find the "data" folder
Add X to the %PATH%
Check: in any shell, try "flex --version" and "bison --version"
So far for the tools. Now we need two libraries that must be statically linked to Qt (magic learned from https://stackoverflow.com/a/41815812/1017348):
Build static zlib:
Download https://zlib.net/zlib1211.zip
Unpack to C:\Development\zlib-1.2.11
Edit the file win32\Makefile.msc with an editor that can handle Unix EOLs:
Find the line starting with CFLAGS
Replace -MD with -GL -MT -Zc:wchar_t-
Find the line starting with LDFLAGS
Replace -debug with -opt:icf -dynamicbase -nxcompat -ltcg /nodefaultlib:msvcrt
Build zlib using the following command (should take less than a minute):
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -DNDEBUG -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Check: as a result, the source directory must contain zlib.lib (856kB), inter alia.
Build static openssl library:
Download https://www.openssl.org/source/openssl-1.1.1.tar.gz
Unpack to C:\Development\openssl-1.1.1
Copy files from zlib: cd zlib-1.2.11; xcopy zconf.h ..\openssl-1.1.1\ ; same for zlib.h zlib.lib zlib.pdb
cd ..\openssl-1.1.1
perl Configure VC-WIN64A no-asm no-shared zlib no-zlib-dynamic threads --prefix=C:\opt\local_x64
note: I added "no-asm" to avoid installation of NASM (Netwide Assembler)
note: I changed prefix, since only admins can install to C:\Windows
Edits the file ''makefile'':
Find the line that starts with: CFLAG
Append: /Zc:wchar_t- /GL /Zi
Find the line that starts with: LDFLAGS
Replace /debug with /incremental:no /opt:icf /dynamicbase /nxcompat /ltcg /nodefaultlib:msvcrt
Find the line that starts with: CNF_EX_LIBS
Replace ZLIB1 with zlib.lib
Build: "nmake"
Check: directory must contain openssl.lib (size?)
Now we are ready to build qtbase from source, using the command-line version of the Visual Studio C++ compiler:
Download (update location for latest Qt): https://download.qt.io/archive/qt/5.11/5.11.2/submodules/qtbase-everywhere-src-5.11.2.zip
Unpacking takes ca 20'
Move the source directory to the Local Disk (C:\Development)
To work with Visual Studio, use a specially configured terminal. Use Taskbar>Circle>Search to launch "x64 Native Tools Command Prompt for VS 2017"
cd qtbase...
Check: configure --help
configure -platform win32-msvc2017 -opensource -confirm-license -release -static -openssl-linked no-dbus -no-libpng -no-libjpeg -nomake examples -nomake tests -prefix C:\opt\local_x64 -I C:\Development\openssl-1.1.1\include -L C:\Development\openssl-1.1.1 -D OPENSSL_LIBS=C:\Development\openssl-1.1.1\libssl.lib
while debugging "configure", it may be necessary to delete config.cache.
option -I does not work with relative paths
the label "win32" may look wrong if we want to use Qt in a 64bit application, but we are advised not to worry: building Qt under Windows: really with "-platform win32-msvc2017"?
I don't know how to get rid of Sql: https://bugreports.qt.io/browse/QTBUG-71253
libpng and libjpeg are needed by optional code. They are provided in src/3rdparty, which tends to provoke clashes with system provided library versions. Therefore, we build without PNG and JPG support.
nmake
Check: static libraries (big .lib and small .prl) land in directory lib/
54.7 MB Qt5Core.lib
23.4 MB Qt5Widgets.lib
18.2 MB Qt5Gui.lib
07.4 MB Qt5Network.lib
...
That's it, we have static Qt libraries. Only, as said above, this did not help me when I tried to link my application with these libraries.
1. cmake is a command from CMake software: preparation for build automation system; make and make install are commands from Make software: build automation system.
2. From reading this post, what I understand is that:
a. This "cmake and make" stuffs actually use g++ / gcc in its implementation. cmake and make stuffs are basically just tools in using g++ / gcc. Is that correct?
b. gcc / g++ are the compiler that do the actual work.
c. So I can just use gcc / g++ directly without using the make and CMake things?
3. According to this stackoverflow answer: CMake takes a CMakeList.txt file, and outputs it to a platform-specific build format, e.g., a Makefile, Visual Studio, etc.
However when I came across this openCV installation :
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local ..
It executes cmake command in a directory where there is no CMakeLists.txt file. Can you explain and elaborate on this?
4. The usual steps that I've seen are: cmake, make, sudo make install.
I read this stackoverflow post, what I understand:
(i) make is for building the project.
(ii) make install is to copy the binary / executables to the installed directories.
a. So when we make, where are the result / binary files / executables stored at?
b. If we only run make without make install, does it mean that the files are not generated?
c. I came across this openCV tutorial on using openCV with GCC and CMake. It uses:
cd <DisplayImage_directory>
cmake .
make
Why doesn't it do make install as well?
5. In summary:
CMake takes CMakeList.txt file (which is cross platform) to generate a Makefile (which is specific to a platform).
I can just write Makefile manually and skip the CMake step. but it is better to do with the CMake step because it is cross platform, otherwise I have to rewrite the Makefile again if I change platform.
Make takes Makefile (which is generated by CMake or written manually) as a guide to compile and build. Make basically uses gcc / g++ or other compiler in its work. Make itself is just a tool for the compiler.
Make install put the result / executables into the install path
CMake generates files for other build systems. These can be Makefiles, Ninja files or projects files for IDEs like Visual Studio or Eclipse. The build files contain calls to compilers like GCC, Clang, or cl.exe. If you have several compilers installed, you can choose one.
All three parts are independent. The compiler, the build system and CMake.
It is easier to understand when you have the history. People used their compiler. Over time they added so many flags, that it was cumbersome to type them every time. So they put the calls in a script. From that the build systems (Make, Ninja) evolved.
The people wanted to support multiple platforms, compilers, scenarios and so on and the build system files became hard to maintain and their use was error-prone. That's the reason people invented meta build system that creates the files for the actual build system. Examples are Autotools or CMake.
Yes
CMake does not use your compiler, make does not implement it, but it calls (uses) the compiler.
The CMakeLists.txt file should be in the parent directory of release. The last argument of the CMake call indicates the path where the CMakeLists.txt file is located.
Right, make generates the file in the build directory. In your example from 3. release is the build directory. You can find all the generated files and use them. Installing is optional, especially if you want to develop the software, you are not installing it.
Try writing Makefiles for a large project and you will see how much work it is. But yes, everything in 5 is right.
I've done everything, and it's payed off.
Trying to compile a mex file from MATLAB using the Windows 7.1 SDK.
~ I've created an compiled my C source code on GCC
~ I've created a MEX file that links and compiles fine via GCC on both Linux and OS X. Does not crash MATLAB, gateway function works fine
~ After much confusion, I switched my dev platform form 64-bit to x86 Win7
~ I've found .dll built files, but they do not link. Linking libs in MATLAB using MATLAB's linker flags will default to .lib, so...
~ I've found--after much googling--simple, pre-compiled x86 GSL .lib's and source files and linked them with MATLAB, eliminating any gsl_blas.h-and-it's-dependencies unrecognized external symbol errors
~ I've re-written every single variable declaration in my source code such that it is C89 standard compatible
~ I've set linker flags appropriately to avoid LIBCMT and any other LIB conflicts
~ I've installed the 2010 and 2012 VC C Runtime libraries
~ I've checked to make sure I have msvcrt.dll and msvcp60.dll in my System files
~ I've followed multiple tutorials online on how supposedly link everything together, most of which had nothing broken links or un-replicable results. I didn't find much to go off of for Cygwin or MinGW.
~ I've tried using the Lcc-win32 2.4.1 compiler
If I was doing basic matrix and vector operations, I'd be set, but unfortunately the various decomposition routines I'm utilizing require parts from the cblas library, which I linked as well, but I get ~30 errors all reporting the same thing...
cblas.lib(ctrsv.obj) : error LNK2001: unresolved external symbol __libm_sse2_sqrt_precise
Here's my MATLAB command.
mex -largeArrayDims -IC:\gsl\include -LC:\gsl\lib -lgsl -lcblas LINKFLAGS="$LINKFLAGS /NODEFAULTLIB:libcmt.lib" file1.c file2.c
So, out of options and frustrated out of my mind, I (naturally) come to stack overflow. Anyone have any idea how to solve this one? The only thing I've foudn on google points to wineHQ errors, not very helpful.
And, if possible, I'd rather not try to compile first on VS201X. I have access to whatever version I need, if necessary, but to me that just seems like a redundant step. Maybe I'm spoiled with Unix-based file system management and linking, though.
It's easy to compile the GSL library under MinGW, in fact the process of compiling from sources is exactly identical to that in Linux. Here are the steps I took:
Setup MinGW for Windows. I am using MinGW-w64 but there is also the popular TDM-GCC distribution which comes with a friendly web-installer.
Obtain GSL sources, and extract the tarball (gsl-1.16.tar.gz is the latest as of now)
Compile as usual, I've used the following commands:
$ ./configure --host=x86_64-w64-mingw32 --prefix=/mingw/local --enable-shared --enable-static
$ make
$ make install
It should take several minutes to finish. Maybe you can enable parallel builds to speed up compilation (make -j)
You'll end up with the necessary files installed in /mingw/local with the usual structure underneath (bin, lib, include).
Finally you can compile an example program with:
$ export PATH=/mingw/local:$PATH
$ gcc `gsl-config --cflags` -o main main.c `gsl-config --libs`
Of course if you prefer using Visual C++ as compiler, people out there have prepared solutions to build GSL using Visual Studio (either manually created project files, or using a build system like CMake and the like). See this question for such projects.
A third option is using Cygwin.
I downloaded
Ruben’s build of
Cygwin GCC.
However upon running it seems unable to compile any files
$ touch foo.c
$ gcc foo.c
gcc: error: spawn: No such file or directory
As a workaround, I found this to work
i686-w64-mingw32-gcc foo.c
I had the same problem and solved it by installing the g++ package in addition to gcc-core
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above -- I'm guessing due to incorrectly assumed relative paths???
Executing /usr/bin/gcc works as expected!
In my case, the "problem" was that I had inadvertently injected "/bin" into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the "/bin" from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places... but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
Ruben's builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn't be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn't really the compiler. It's a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can't find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
I had the same error when I tried to extract a couple of executables from cygwin installation dirctory and copied them into another location.
strace shows me the file which was not found by spawn:
/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
When I copied cc1.exe into the location relative to
<dir with sh.exe and cpp.exe>/../lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
it works fine.
This error occurs whenever cygwin cc can't find a required file.
For those running stuff within cygwin's bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
e:cyg/bin/gcc -flags
Notice that there is no slash between e: and cyg.
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
e:/cyg/bin/gcc -flags
Notice the slash in between e: and cyg.
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1. Windows does not give you an error if you are at the root folder and try to go up another folder using ...
So you could start running cygwin gcc using the command:
e:/../cyg/bin/gcc -flags
..or even:
e:/../../../../../../../../../cyg/bin/gcc -flags
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there's no folder to go up to.
As like above, this can be fixed by keeping the path valid:
e:/cyg/bin/gcc -flags
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
$ gcc -o main main.C
$ gcc: error: spawn: No such file or directory
$ gcc -o main main.c
$ # all good
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don't know the actual reason for this behavior.
I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.