The team on which I work produces a shared library for use in Python. This library is entirely C++ and we use Boost to expose to python. Because we cannot guarantee that our clients have the Boost libraries installed, we pull in the functionality needed from Boost to the shared object file statically. The final stage in compilation will look familiar to many
g++ -o <output> <objects> -Wl,-Bstatic -lboost_python -lboost_regex ... -Wl,-Bdynamic -shared <other_opts>
We've traditionally used our own build of Boost: 1.47. This version is now quite old and so we wish to update. However, oddly, when I install the necessary objects using yum on my CentOS 7 system, I get the following error from gcc:
relocation R_X86_64_32 against '.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Well, I thought I'd simply download the latest boost (CentOS 7 installs Boost 1.53) and do my own build. This, after all, has always worked for us. I follow the instructions here but I got the same error. How do I force the use of -fPIC for even the static libraries that it builds?
I believe boost automatically uses -fPIC when compiling a shared library (.so file), but the below command uses -fPIC when compiling a static library (.a file) too.
This worked for me on boost 1.46.1:
sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a ... install
The ... is where you add additional flags like threading=multi or --layout=tagged, and optionally the list of projects to build (for example: --with-regex).
Note: using both cflags and cxxflags is unnecessary, only one is needed. See comments below.
Reference links:
https://cmake.org/Wiki/TubeTK/Build_Instructions#Boost_.28optional.29
http://lists.boost.org/boost-users/2010/07/60682.php
Just for convenience, I combined previous answer and comments to it:
sudo ./bjam cxxflags=-fPIC -a --with-system install
--with-system is not necessary, but it's a place where you can add other boost compile options
It works for me at CentOS 7 with boost 1.67
Another solution:
./bootstrap.sh
./b2 cxxflags=-fPIC cflags=-fPIC
Related
I cannot include the hkdf.h from the crypto++ library into my code.
It says cryptopp/hkdf.h not found. Although I can import other parts from the same library into my code, such as cryptopp/sha.h
I am using the g++ with the -std=c++11 and the -lcryptopp flags
I looked into the docs and it suggested the -lcryptopp flag which I am using. This should not be an issue, am I missing something ?
Edit 1:
Compile command :
g++ -std=c++11 mycode.cpp -lcryptopp
Edit 2:
How do I check the version of my crypto++ library ?
Download command was:
sudo apt-get install libcrypto++-dev
My OS is Ubuntu 16.04
Compile command :
g++ -std=c++11 mycode.cpp -lcryptopp
This does not answer your question. It is just a heads up...
Be careful with g++ -std=c++11 mycode.cpp -lcryptopp. The library and your program have to be built using mostly the same options. I don't believe Debian uses -std=c++11, so you should not use it.
The "use mostly the same options" rule applies to all distros and all C++ libraries; and not just Crypto++ on Debian. You will encounter similar problems if you do the same with the PCRE library on Fedora.
You can check the flags Debian is using to build the library at Debian Package Auto-Building | Crypto++. The flags Debian uses are:
-DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 \
-fstack-protector-strong -Wformat -Werror=format-security \
-DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS -DNDEBUG -fPIC -DPIC
For your purposes the important flags are -g -O2 -DNDEBUG -fPIC. Those flags are the ones you should use with your program. -DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS is applied in the file config.h so you don't need to pass it on the command line. (Unaligned access was removed recently because it caused too many problems, so you don't even have to worry about -DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS in the future).
You can use -std=c++11 if you like. However, you have to download and build the library yourself from sources to ensure the same flags are used by the library and your program.
If you build the library yourself then see GNUmakefile | Building the Library on the Crypto++ wiki.
If you build the library yourself then do yourself a favor and remove the distro provided version of the library. Something like sudo apt-get remove --purge libcrypto++ libcrypto++-dev libcrypto++-dbg. Otherwise you will inadvertently be mixing and matching them.
Cannot include the hkdf.h from the crypto++ library into my code.
It says cryptopp/hkdf.h not found.
HKDF was added at Crypto++ 5.6.3. Older versions of the library do not have it, like one supplied on Ubuntu 14 or CentOS 5.
It is a header-only implementation using the file hkdf.h. You can download it and drop it in the Crypto++ installation directory. Maybe something like the following for Crypto++ 5.6.3:
# Crypto++ 5.6.3
wget https://raw.githubusercontent.com/weidai11/cryptopp/217cb1f983c6/hkdf.h
sudo cp hkdf.h /usr/include/cryptopp/
The key derivation functions interface changed at Crypto++ 7.0. More correctly, at Crypto++ 7.0, we added a base class to use as the interface (previously there was none). The base class is KeyDerivationFunction, and it allowed us to improve self tests for the key derivation function classes. So maybe something like the following for Crypto++ 7.0:
# Crypto++ 7.0
wget https://raw.githubusercontent.com/weidai11/cryptopp/c8d8caf70074/hkdf.h
sudo cp hkdf.h /usr/include/cryptopp/
To summarize:
Crypto++ 5.6.3: you only need the file that supplies HKDF
Crypto++ 7.0: you need the files that supply both KeyDerivationFunction and HKDF.
Put another way, if you try to use Crypto++ 7.0 HKDF with Crypto++ 5.6.2, then it will never compile because KeyDerivationFunction is missing from the library.
This should not be an issue, am I missing something ?
I think your problem is probably dependent on your distro (or whomever is supplying Crypto++). We could say more if you provided details of the distribution and the library version they supply.
To hazard a guess... Debian and Fedora stay up to date with the Crypto++ releases. Or they have for the last several years. So you are probably not using Debian 8, Ubuntu 17, Fedora 22 or their respective variants.
However, you may be using Debian 7 or earlier, Ubuntu 12 or earlier, or Fedora 21 or earlier. In this case I believe you are using Crypto++ 5.6.2.
I believe Gentoo, the BSDs and some others are behind on the release curve. As far as I know, some distros are still providing Crypto++ 5.6.2.
So I follow the official tutorial for the installation : https://mongodb.github.io/mongo-cxx-driver/mongocxx-v3/installation/
Neverless, I can't use the produced libraries as static.
So I managed to compile the C version of the driver as described, I've enabled the flag --enable-static=yes with the ./configure before doing make && sudo make install and I got the libmongoc-1.0.a and the libbson-1.0.a which are static. So this far, everything it's alright.
Then I have done the cxx version of the driver, except that there is no configuration file as in the C version. So I've juste done a
cmake -DCMAKE_BUILD_TYPE=Release -DBSONCXX_POLY_USE_BOOST=1 -DCMAKE_INSTALL_PREFIX=/usr/local
from the build folder, followed by a make && sudo make install
So I got the libmongocxx.a and the libbsoncxx.a, but when I try to compile with them, I can't run the binary because I got the following error :
error while loading shared libraries: libmongocxx.so._noabi: cannot open shared object file: No such file or directory
So I understand that is because there is some symbols missing and then I need to use the shared library to run the binary but I don't want this to happend, I want the symbols within the binary that I can run it without any LD_PRELOAD.
Any suggestions ?
I had the same issue in an Ubuntu 16.04 and I run a apt-get update & apt-get upgrade and the problem was solved.
It seems that there were some update to the compiler and some libraries that prevent some test from reaching the shared libraries.
I have a similar question, and solved, now I compiled and run my binary with static libs successfully.
I write my build script using newlisp, but the static link options are very helpful, I paste it here.
c++ /to/your/path/site/code/back_end/builder/object/files1.cc.o ... /to/your/path/site/code/back_end/builder/object/files10.cc.o -o bin/site -static-libgcc -static-libstdc++ -L/usr/lib -lpthread -l:libmongocxx.a -l:libbsoncxx.a -l:libmongoc-1.0.a -l:libbson-1.0.a -lrt -lssl -lcrypto -lsasl2 -l:libboost_log.a -l:libboost_log_setup.a -l:libboost_system.a -l:libboost_thread.a -l:libboost_filesystem.a -lcppcms -lbooster -lcurl -ljsoncpp
When linking my project in the release mode I am getting the following warning:
myProject-libs/release/libboost_regex-mt-s-1.50.0.a(cpp_regex_traits.o): duplicate section `.data$_ZZN5boost16cpp_regex_traitsIcE21get_catalog_name_instEvE6s_name[boost::cpp_regex_traits<char>::get_catalog_name_inst()::s_name]' has different size
I suspect that the cause could be that the boost library is compiled with different options than I use for my project, but I don't know how to find the difference (boost didn't output these options during the build).
In order to compile the boost for win32 on Ubuntu 12.04 I used this procedure:
tar jxf boost_1_50_0.tar.bz2
cd boost_1_50_0
./bootstrap.sh
echo "using gcc : 4.6 : i686-w64-mingw32-g++ : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar ;" > user-config.jam
./bjam toolset=gcc target-os=windows --address-model=32 variant=release threading=multi threadapi=win32 link=static runtime-link=static --prefix=/opt/boost_1_50_0-release-static-windows-32 --user-config=user-config.jam -j 10 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
In order to compile files in my project I use something like
i686-w64-mingw32-g++ -march=corei7 -mfpmath=sse -m32 -Wall -fmessage-length=0 -I"/opt/boost_1_50_0-release-static-windows-32/include" -std=c++0x -O3 -g0 -DNDEBUG -I"myProject/src/cpp" -c -o myProject/build/release/src/cpp/myproject.o myproject/src/cpp/myproject.cpp
The tests I have indicate that the regexps run fine but still I would like to resolve the warning.
EDIT
I found that additional options to the boost compiler can be added using a cxxflags= argument of bjam.
Example:
bjam cxxflags='-fPIC' ....
Maybe making sure to pass the same arguments as I do to the project could resolve the problem (particularly the arguments related to optimizations as suggested in the linked question).
Your compilers were compiled with different options :) Compiling the library on Linux and the program on Windows result in a situation where there is an identically named .data segment, but they aren't the same size. That could theoretically be interesting, inasmuch as a data segment is writable, but in practice, it shouldn't matter. Unless there is evidence to suggest this causes a problem of which I'm not aware, you can safely suppress that warning; I don't know how you'd make it go away, though.
I recently encountered this problem (i.e. linker warning "duplicate section has different size") when trying to compile boost for Windows using mingw.
The issue I had was that I compiled my application with -std=c++14 but when compiling boost I didn't specifically provide a dialect flag (which defaulted to -std=c++98 for g++ 5.3.0). Adding the dialect flag -std=c++14 when compiling boost solved the problem for me. See this answer for an explaination on how to set cxxflags when compiling boost.
I believe my solution might have worked for you (your application was compiled with -std=c++0x but boost was not provided any dialect flag). Although I am 6 years too late, I'll leave my answer here for others who happen to stumble-upon this issue.
I installed Boost via sudo apt-get install libboost-all-dev on the most recent version of Ubuntu. Now I want to compile a project that uses the Boost.Serialization library, which needs to be linked.
I've tried many variants of the following, without success:
gcc -I /usr/lib code.cpp -o compiled /usr/lib/libboost_serialization.a
and
gcc -I /usr/lib code.cpp -o compiled -l libboost_serialization
The error message is:
error: ‘split_member’ is not a member of ‘boost::serialization
`
What am I missing?
You are having troubles with compiling your code, not linking. On that stage it has nothing to do with libraries. At that point the fact that you have to link against something is irrelevant.
Make sure you are including boost/serialization/split_member.hpp directly or indirectly and get your code compiled first.
On a side note, -I flag is used to specify path to include files and not libraries. For libraries, use -L. But if you have installed Boost from apt, then it should already be in the path and so no additional -I or -L should be required. And when you specify -l, you have to emit lib from the beginning of library name and not put a space between a flag and its argument. Assuming working code, something like this should do:
g++ code.cpp -o compiled -lboost_serialization
I'd also recommend you pass -Wall flag to make compiler be more verbose and warn you about possible mistakes in your code.
split member is a problem with compiling where boost is assuming there are split calls for serialize and deserialize.
http://www.ocoudert.com/blog/2011/07/09/a-practical-guide-to-c-serialization/
I'm trying to build a 32-bit application on Ubuntu 11.04 x64. I'm having some issues with the build because of linker errors with libboost. The build statement has -lboost_system in it, but when I try to build I get a bunch of these:
CommunicationModule.cpp:(.text+0x68c1): undefined reference to boost::system::generic_category()
CommunicationModule.cpp:(.text+0x68d7): undefined reference to boost::system::system_category()
Everything I've found on google says I need to link to the boost_system library. One place I found says to try linking to it directly, but when i do locate boost_system the result is empty. When I try doing a sudo apt-get install libboost-system-dev it tells me that it's already installed. I'm kind of at a loss here. The library is installed, but it's not being found by locate?
Can anyone tell me what I need to do to properly link to boost::system? I'm fairly new to linux and the complexities of compilers so any help here would be appreciated.
Update:
Here is the output of dpkg -L libboost-system1.42-dev:
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libboost-system1.42-dev
/usr/share/doc/libboost-system1.42-dev/copyright
/usr/share/doc/libboost-system1.42-dev/NEWS.Debian.gz
/usr/share/doc/libboost-system1.42-dev/README.Debian.gz
/usr/lib
/usr/lib/libboost_system.a
/usr/lib/libboost_system-mt.so
/usr/lib/libboost_system-mt.a
/usr/lib/libboost_system.so
Is there a flag I can use to link to one of these directly? I tried using -L /usr/lib/libboost_system.so and -L /usr/lib/libboost_system-mt.so and neither of those fixed the issue. Same with just adding /usr/lib/libboost_system.a and /usr/lib/libboost_system-mt.a to the build statement.
Here is the compilation line:
g++ -m32 -Wl,-O1 -o UTNaoTool [.o files] -L/usr/lib32 -lqglviewer-qt4 -lqwt-qt4 -lboost_system -lboost_thread -lQtXml -lQtOpenGL -lQtGui -lQtNetwork -lQtCore -lGLU -lpthread
Update 2:
I downloaded boost 1.49 and built everything for 32-bit and that seemed to help. A lot of the errors went away, but now I still have these:
CommunicationModule.cpp:(.text+0x68c1): undefined reference to
boost::system::get_generic_category()
Note that the function is different. So all of my errors are regarding undefined references to get_system_category() and get_generic_category() now. I tried adding a -lboost_filesystem to the build command but that didn't fix this, and I made sure it was referencing the 32-bit library that I built when I built libboost_system.
Looking at my own installation, it seems libboost-system-dev does not install the libraries. Using dpkg to tell me what was installed bz libboost-system-dev I get:
$ dpkg -L libboost-system-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libboost-system-dev
/usr/share/doc/libboost-system-dev/copyright
/usr/share/doc/libboost-system-dev/changelog.gz
Poking around, I think you need to install libboost-system1.48.1 (or some other version).
sudo apt-get install libboost-system1.XX.Y
You can also search fo rthe libraries using the find command, for example, search under /usr for all files starting with libboost_system:
find /usr -name "libboost_system*"
Edit: Since you are cross-compiling from a 64 bit OS to a 32 bit one, you need 32 bit versions of the boost libraries. I would be tempted to set up a small 32 bit virtual machine to do this, rather than cross-compiling all the dependencies.
I had the same problem with boost_serialization here is what i found out after couple of googling..
first this library need to be compiled separately :
so after downloading the boost library ,extract it and execute sudo ./bootstrap.sh' then
sudo ./b2 --with-system
after this step you should be find a result when executing locate boost_system
then to link it manually I did:
both should work
g++ boostexample.cpp -o run /PATH/libboost_serialization.a
g++ boostexample.cpp -o run -L/PATH/ -lboost_serialization
well this is a little work around and I'm still looking for how to link the library properly
I hope this helped :)