I'm having my first fling with the Boost libraries, and I've picked a pretty girl named Regex.
I've installed the libraries (which build automatically?) on my machine, but I'm getting the above error (cannot find -lboost_regex). I'm using Code::Blocks with MinGW, and a C++0X compiler flag.
I have
Pointed the "search directories" to the installation directory
Added the -lboost_regex flag to the linker
but no luck. Can someone help me get this working?
Update
Got things running now. I've added some further notes in an answer below, for newcomers to this problem.
(Also, changed the title of the question since it turned out to be a broader issue than when I started out.)
Here's some links and tips that can help a newcomer, from my first build experience. I built the libraries directly from the zip file. I built on MinGW and I used CodeBlocks for the IDE.
Download Boost zip, unzip somewhere (I'll call that place $boostdir)
Pretty large when unzipped, > 300MB
Add MinGW bin to PATH var
When Boost builds, it will need access to MinGW executables
Build b2.exe and bjam.exe
The documentation for Windows blithely assumes MSVC compiler is available.
If it is, you can apparently use the bootstrap.bat like the docs say.
If it's not (like mine), you'll have to build the exe files yourself, in steps 4 and 5.
In CMD, navigate to $boostdir/tools/build/v2/engine
Run build.bat mingw (will build b2.exe and bjam.exe)
Some aging basic documentation on that
Now you've got b2 and bjam custom-built according to your system spec. Navigate back up to $boostdir and get ready to start building the libraries.
Boost will make a new bin.v2 directory in the current directory.
All the libs will go in bin.v2.
This is an "intermediate" directory, for some reason
Nothing to do in this step, just some extra info :)
Run b2 toolset=gcc --build-type=complete
This takes a long time, in the neighborhood of 1 - 2 hours.
You'll know if it's working. If you think something's wrong, it's not working.
The build can use various flags
Now you're all built. Time to set up CodeBlocks.
Point your compiler to the header files
Right click your project -> Build Options -> Search Directories tab -> Compiler tab -> add $boostdir address
Boost has built a DLL for the library you want according to your current system spec. Look in the stage\lib\ directory of $boostdir
This DLL will be used later in the linker, so don't close its explorer window yet
Mine was in C:\Program Files\Boost_1_52\stage\lib\libboost_regex-mgw44-1_52.dll
I think the documentation had a smart way to do this but I haven't tried it yet
The "intermediate" directory from step #6 can be deleted now that the build is finished
Point your linker to the directory of that DLL
Right click your project -> Build Options -> Search Directories tab -> Linker tab -> add
that directory address (blah\blah\blah\stage\lib\)
Add that DLL flag to your linker settings
Mine was -lboost_regex-mgw44-1_52
Deep breath, prayers to your god, and fire up a test.
Further docs that may either help or confuse:
The Code::Blocks website has a version of this that I didn't find until I neared the end of my search. It was fairly helpful but had a few weird things. This post also is helpful.
Good luck!
I'm not sure what you mean by which build automatically. Most of the Boost libraries are header-only, but a few, such as regex, need to be compiled to a shared / static library. The compilation step is not automatic, you need to invoke the Boost build system (bjam) to do this. Of course, there are sources (BoostPro for instance) that distribute pre-built Boost binaries for various platforms.
Once that's done, you need to add the path where the libraries are present to the linker's search path. For MinGW, this option is -L"path/to/library". Boost does have directives to allow auto-linking of the required libraries, and this seems to work pretty well with MSVC, but I've never gotten it to work with MinGW. So you must also list the libraries to be linked explicitly. The Boost libraries include target and version information in the file name by default, so a typical linker command line option will look like -lboost_regex-mgw47-mt-1_51 for MinGW gcc 4.7 and Boost 1.51
Related
My advance appologies for being hopeless at Windows development. I am by no means a Windows developer and my understanding of how to write, compile and link C++ code on a Windows system is limited to say the least.
I am having difficulty trying to compile and link a SFML project on a Windows 10 system with the CodeBlocks IDE.
I am trying to link this project with static linking, not dynamic linking. Again I have virtually no idea how the two different methods work in detail, I just know that if I ship a static linked binary to another Windows 10 user it is much more likely to "just work" on their system.
List of things I did:
Downloaded the latest version of CodeBlocks with MINGW integration.
Installed, default options
Downloaded the latest version of SFML (32bit MINGW version)
Extracted the zip file (SFML) to my home directory
Created a new codeblocks project (console application) and followed the instructions to set the compiler and linker options
https://www.sfml-dev.org/tutorials/2.5/start-cb.php
It works fine for dynamic linking, but requires me to copy the .dll files to the same dir as the produced executable file (produced from compilation of my C++ code).
I tried to change to static linking, changing the names of the linker libs with the -s or -s-d suffix, and adding the define SMFL_STATIC option to global (release and debug) options. I also added the opengl32, freetype, winmm and gdi32 link libs, before their respective sfml link libs.
When trying to compile I get the following linker errors
cannot find -lfreetype
cannot find -lsfml-graphics-s-d
cannot find -lsfml-window-s-d
cannot find -lsfml-system-s-d
in Release mode, similar errors are produced.
What am I doing wrong?
My hunch would be that you either have the wrong compiler (see below) or you haven't defined the library directory as mentioned in the linked tutorial.
There are four common things to consider when using SFML (and essentially any other C++ library) on Windows.
Compiler versions have to fully match
Make sure to not mix x86 and x64
Settings need to be specified for the correct configuration
When linking libraries statically, you also need to link the dependencies
Compiler versions have to fully match
Since C++ doesn't have a standardized ABI, the generated libraries will never be reusable between compilers. Yes, sometimes "it works", but it can break at any point and there's no guarantee.
We strongly recommend to either use the compilers linked on the SFML Download page or build SFML from source with your current compiler.
If you got the latest stable Code::Blocks version with MinGW as stated, you should also be able to get a snapshot build of SFML, which should be using the same compiler.
Note: One exception to this rule is Visual Studio, where VS 2017 binaries are compatible with VS 2019 (and maybe VS 2022?).
Make sure to not mix x86 and x64
When you download a 32-bits (x86) version of SFML, you also need a 32-bits version of your compiler. When you download a 64-bits (x64) version of SFML, you also need a 64-bits version of your compiler.
Make sure you double check your compiler configuration that you've selected the correct bit-ness.
Note: For Visual Studio you need to select the correct compiler architecture in the IDE, usually positioned right next to the run button.
Settings need to be specified for the correct configuration
Project configurations are usually spread across the matrix built from the types:
Debug / Release / All
x86 / x64 (for VS)
Make sure when you add the settings for library paths and include paths that it's not just set for debug or release and ends up missing in either or the other configuration.
Also make sure you're not setting up debug libraries (with the -d suffix) in release mode or release libraries (without any suffix) in debug mode.
When linking libraries statically, you also need to link the dependencies
The SFML static libraries don't contain any symbols of any of its dependencies, that means, in your final application you have to link static SFML and all its dependencies.
As a short summary you can think of static libraries like an archive of object files. These object files will directly be linking into your application, like you link your own source file object files. As such, the SFML static libraries only contain object files of SFML itself and not of other libraries as well.
Troubleshooting
If nothing seems to help, then you should enable verbose compiler & linker output, that we you see exactly which commands are invoked and one can quickly spot the missing statements.
Hi I am having problems with trying to get sfml going with netbeans. Here is a short video of what I have done. video
After listening to HEKTO I now downloaded the MSYS. I removed the static libraries and get this error now:
The application failed with exit code -1073741515 (0xc0000135).
This could indicate that no required .dll was found in the PATH.
Please try to start the following command from the command shell (cmd.exe).
This may give some additional information.
C:\Users\david\Documents\NetBeansProjects\tester\dist\Debug\MinGW_1-Windows\tester.exe
RUN FAILED (exit value -1,073,741,515, total time: 58ms)
After adding system path.. heres new img:
system path img
The SFML developers recommend the exact match between your MinGW version and your SFML version - please see this page, especially these three lines:
The compiler versions have to match 100%!
Here are links to the specific MinGW compiler versions used to build the provided packages:
TDM 5.1.0 (32-bit), MinGW Builds 7.3.0 (32-bit), MinGW Builds 7.3.0 (64-bit)
Your MinGW compiler is 8.2.0 - it doesn't match. So you'll need to download the MinGW using links from this page and install it manually.
Also you try to link with static libraries (with suffix _s). In this case you have to add other libraries to the linker setup - please see here. If to use dynamic libraries then you won't need any additional libraries, however the SFML directory with its DLLs will need to be added to the system path.
UPDATE. Your question has been rewritten many times, so my answer has become irrelevant - this is not good, the question can be updated to improve it, but please not to rewrite it completely following additional information given to you in comments. References to videos and pictures aren't welcomed here also. Your question must be self-contained and potentially helpful for others, looking for help in similar situations.
That said I'll add two tips for future generations:
Don't use relative paths for include and lib directories in the NetBeans compiler and linker setup - use only absolute paths.
MinGW distributions, referenced on the SFML downloading page, don't contain the MSYS (small collection of Unix tools, which includes make.exe). You'll need to download and install the MSYS separately, for example using the MinGW installer with msys-base package only.
I'm wondering how to "package" a C++ project for release. It uses various libraries, and I don't want a user to have to go through the same setup I did, with putting the right files in the right place and such. I had difficulty researching this, because I'm not sure the technical term for this issue. If I'm using command line compiling on Linux, is there an easy way to do this?
Your approach to this will differ on Windows and Linux because each OS handles this a different way. I'm more familiar with Linux so I'll restrict my answer to just the Linux side of things.
When you link your executable with a library using -l flag the linker defaults to looking in the normal system library directories so there are four approaches here.
Require the user to properly install the libraries themselves. However, it sounds like you don't want to do that.
Have the user add the library location to LD_LIBRARY_PATH variable.
Your third option is force the linker to look in a certain path for the libraries using the -rpath flag. For example, to have the application look in its working directory for a shared library you can compile with: g++ -rpath ./ -l SomeLib -o MyApp myapp.cpp
One other option is to static link your code with their library that way you only have to distribute one executable. If a static library exists you can use g++ -static -l SomeLib -o MyApp myapp.cpp to tell gcc to link statically.
On windows I would recommand wix http://wix.sourceforge.net/ to create the .msi installer
I would like to point out, the lookup path for .dlls I recommand putting all .dll in the same folder as your .exe since this has the highest priority
However, the vc crt (the c/c++ runtime library) should be installed using the redistributional package from microsoft -> updates automatically http://www.microsoft.com/de-de/download/details.aspx?id=5555
Wix can include the redistributional package into the same .msi therefore you have only to deploy a single installer file.
You mean an installer?
On Windows the program that you run to install a new app which outs everything in the correct directory, creates the start menu and lets you un-install it?
There is an installer builder in Visual Studio (might not be in the free express version) which makes .msi installer files. It's fairly easy to use for simple tasks but becomes complicated to do anything more.
Alternatively, to create traditional setup.exe type installs I use the excellent free Innosetup
On linux you would generally create a package using whatever format your distribution uses (.deb / .rpm ). There are lots of instructions on the specifics of each one and the tools to do so will probably already be installed in your Linux system
I'm trying to run some simple examples with Boost and I'm continuously running into this error and I have tried to compile this but I haven't been able to create "libboost_system-vc100-mt-gd-1_46_1.lib".
I keep ending up with this issue:
error LNK1104: cannot open file 'libboost_system-vc100-mt-gd-1_46_1.lib'
Anyone encounter this error before? How do you compile this properly with NMAKE because it keeps telling me it's bulding "boost.regex without ICU / Unicode Support" which is giving it a "fatal error U1073 and tells me it doesn't know how to make "../src/c_regex_traits.cpp".
Sorry if this is a jumble it's just a lot of information that's getting more and more confusing to me.
Your boost is not properly built or installed. Please follow the instruction on how to install boost.
You need to build the boost libraries first.
To do this, open command line & go to boost root eg C:\dev\boost\1_46_1.
Depending on whether you want to build for 64bit or 32bit applications, type
(x64):bjam toolset=msvc address-model=64 variant=debug,release link=static threading=multi runtime-link=static,shared stage
(x86): bjam toolset=msvc variant=debug,release link=static threading=multi runtime-link=static,shared stage
to start compiling. Be patience while boost is building, it takes a lot of time. When building is complete you can find the library files in "stage\lib" folder.
Also note that you can delete the folder "bin.v2" once building is complete.
Now you need to point your VS2010 project to those libraries. Modifying part of mlimber's answer:
In VS2010, right-click on your project, select Properties and then go to Configuration Properties -> Linker -> General. Look for "Additional Library Directories" in the middle of the list, and add C:\Program Files\Boost\boost_1_46_1\lib (or whatever) there.
Another way to do this is the following
In VS2010, right-click on your project, select Properties and then go to Configuration Properties -> VC++ Directories. Look for "Library Directories" in the middle of the list, and add C:\Program Files\Boost\boost_1_46_1\lib (or whatever) there.
Apart from the above, one could also download from
http://sourceforge.net/projects/boost/files/boost-binaries/1.46.1/
the necessary libraries (including the file missing).
While trying to build Pion network library, I ran into a very similar problem since Pion has dependency on Boost library.
My Boost build was built using boostrap and bjam, and not BoostPro.
The error I got was this: LINK : fatal error LNK1104: cannot open file 'boost_thread-vc100-mt-gd-1_46_1.lib'
When I looked at C:\OpenSource\boost_1_46_1\stage\lib directory, I saw every file name started with libboost_ and not boost_. The file boost_thread-vc100-mt-gd-1_46_1.lib was clearly missing. That made me suspicious that not all boost libraries were built by bjam. After a little research, I reran bjam with the option --build-type=complete
Now I noticed that it started creating lib file names starting with boost_. Not to mention, Pion library could now compile successfully.
Hope this adds some clarity to this thread.
Or alternatively to ybungalobill's suggestion use the installer from www.boostpro.com.
In the installer you must just select the boost versions for msvc 10 and after installation update your visual studio include and lib directories in the VS2010 property sheets to point to the boost include and lib directory.
I take it that you used the BoostPro installer, but which library types did you install -- header only, static linking, DLLs, everything?
Assuming you did everything, then the problem is probably that you don't have the path to boost in your library paths. The problematic file name starts with "libboost" which tells me you're trying to use the statically linked version, which is fine. You should add the library path to your Makefile or project settings for all build configurations. It's probably something like C:\Program Files\Boost\boost_1_46_1 (for the newest version on a 32-bit version of Windows).
In VS2010, right-click on your project, select "All Configurations" at the top, then go to Configuration Properties | Linker [or Librarian if you're making a library] | General. Look for "Additional Library Directories" in the middle of the list, and add C:\Program Files\Boost\boost_1_46_1\lib (or whatever) there.
Do that for each project in the solution that uses Boost libraries that are not header-only.
For a Makefile, you'll have to locate the library paths and add Boost to it similarly but by hand.
My development shop has put together a fairly useful Python-based test suite, and we'd like to test some Linux-based C++ code with it. We've gotten the test project they ship with Boost to compile (type 'bjam' in the directory and it works), but we're having issues with our actual project.
Building the boost libraries and bjam from source (v1.35.0), when I run bjam I get a .so in the bin/gcc-4.1.2/debug directory. I run python and "import " and I get:
ImportError: libboost_python-gcc41-d-1_35.so.1.35.0: cannot open shared object file: No such file or directory
Looking in the library directory, I have the following:
libboost_python-gcc41-mt-1_35.so libboost_python-gcc41-mt-1_35.so.1.35.0 libboost_python-gcc41-mt.so
Obviously I need the -d instead of the -mt libraries, or to point at the -mt libraries instead of -d, but I can't figure out how to make my Jamroot file do that.
When I install Debian Etch's versions of the libraries, I get "No Jamfile in /usr/include" - and there's a debian bug that says they left out the system-level jamfile.
I'm more hopeful about getting it working from source, so if anyone has any suggestions to resolve the library issues, I'd like to hear them.
Response to answer 1: Thanks for the tip. So, do you know how I'd go about getting it to use the MT libraries instead? It appears to be more of a problem with bjam or the Jamfile I am using thinking I am in debug mode, even though I can't find any flags for that. While I know how to include specific libraries in a call to GCC, I don't see a way to configure that from the Boost end.
If you want to build the debug variants of the boost libraries as well, you have to invoke bjam with the option --build-type=complete.
On Debian, you get the debug Python interpreter in the python2.x-dbg packages. Debug builds of the Boost libraries are in libboost1.xy-dbg, if you want to use the system Boost.
Found the solution! Boost builds a debug build by default. Typing "bjam release" builds the release configuration. (This isn't listed in any documentation anywhere, as far as I can tell.) Note that this is not the same as changing your build-type to release, as that doesn't build a release configuration. Doing a 'complete' build as Torsten suggests also does not stop it from building only a debug version.
It's also worth noting that the -d libraries were in <boost-version>/bin.v2/libs/python/build/<gcc version>/debug/ and the release libraries were in <gcc-version>/release, and not installed into the top-level 'libs' directory.
Thanks for the other suggestions!
One important Point: -d means debug of course, and should only be linked to a debug build of your project and can only be used with a debug build of python (OR NOT, SEE BELOW). If you try to link a debug lib to a non-debug build, or you try to import a debug pyd into a non-debug python, bad things will happen.
mt means multi-threaded and is orthogonal to d. You probably want to use a mt non-d for your project.
I am afraid I don't know how to tell gcc what to link against (I have been using Visual Studio). One thing to try:
man gcc
Somewhere that should tell you how to force specific libs on the linker.
EDIT: Actually you can import a debug version of you project into a non-debug build of python. Wherever you included python.h, include boost/python/detail/wrap_python.hpp instead.