I am compiling a project that needs boost::filesystem. I have included the following flags in my compilation step:
g++ -Wall -ggdb -Werror -std=c++11 -lboost_system
-lboost_filesystem -I /custom/path/to/boost_1_67_0
-o build/main build/cp.o build/walk.o build/diff.o build/main.o
and I get an error:
build/cp.o: In function `boost::filesystem::relative(boost::filesystem::path const&, boost::filesystem::path const&)':
/custom/path/boost_1_67_0/boost/filesystem/operations.hpp:690: undefined reference to `boost::filesystem::detail::relative(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)'
build/cp.o: In function `boost::filesystem::weakly_canonical(boost::filesystem::path const&)':
/custom/path/boost_1_67_0/boost/filesystem/operations.hpp:728: undefined reference to `boost::filesystem::detail::weakly_canonical(boost::filesystem::path const&, boost::system::error_code*)'
collect2: error: ld returned 1 exit status
make: *** [build] Error 1
I suspect that this is due to the fact that I have various other boost::filesystem binaries, some of which don't have relative and weakly_canonical in their versions. I don't really know where to supply the argument to specify the location of the binaries either. I suspect it's something to do with the flags lboost_system and lboost_filesystem where I can supply the location.
I am currently in process of building the .so's but I can see that the filesystem .so is already successfully built at /custom/path/boost_1_67_0/bin.v2/libs/filesystem/build/gcc-4.8.5/release/threading-multi/libboost_filesystem.so.1.67.0, so I want to point to that in the mean time. Building the library is taking a really long time.
So is it the -lboost_{libname} flags that I can extend upon? Is it the -I flag?
EDIT: Now that the binary location specified by --prefix during build is done, I tried the same thing, even with -L and it didn't work. Refer to my answer below for the LD_LIBRARY_PATH solution.
I have a solution, but it's not pretty:
I suspect it's because the other boost library binary is specified in $LD_LIBRARY_PATH, I could not load my own library in precedence using -L /custom/path/....
Thus, I did:
export LD_LIBRARY_PATH=/custom/path/...:$LD_LIBRARY_PATH
And it works.
This is by no means a good answer because it doesn't really make this build process portable to users without the LD_LIBRARY_PATH flag. Better answers will be approved instead of this.
Looks like you still need to provide the -L GCC option.
Use -L to tell the compiler where to look for the boost libraries.
Also, make sure you used bjam/b2 to install boost in a proper place. That bin.v2 directory is used to build boost libraries and not install.
Related
I have installed the GMP library and try to cross-compile with mingw-w64-posix.
My Library is in /usr/local/lib.
My compile command looks like the following:
x86_64-w64-mingw32-g++-posix src/factorial.cpp -o bin/factorial.win.o -I/usr/local/include -L/usr/local/lib -lgmp -lgmpxx
It throws an undefined reference error:
(I can remove the whole block from -L...., same error. Seems like the library doesnt link for some reason)
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3_[_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3_]+0x27): undefined reference to `__gmpz_mul'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_l[_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_l]+0x26): undefined reference to `__gmpz_mul_si'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_E7init_siEl[_ZN10__gmp_exprIA1_12__mpz_structS1_E7init_siEl]+0x1a): undefined reference to `__gmpz_init_set_si'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EOS2_[_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EOS2_]+0x2e): undefined reference to `__gmpz_init'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_ED1Ev[_ZN10__gmp_exprIA1_12__mpz_structS1_ED1Ev]+0x14): undefined reference to `__gmpz_clear'
collect2: error: ld returned 1 exit status
However if i change my compiler to g++ instead everything works fine.
OK -
The link errors (__gmpz_init, __gmpz_clear, etc.) are GMP "internals". They're supposed to come from libgmp, the C-language base library.
The code that's referencing them (.text$ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3[ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3], etc.) is "name mangled" C++.
I suspect the problem is that your "gmpxx" library was built with a different C++ compiler, that has a different "name mangling" convention than MinGW.
SOLUTION:
Download the complete libGMP source (e.g. from https://gmplib.org/, and rebuild EVERYTHING (including libgmpxx) with your libmingw-w64-posix++ C++ cross-compiler.
ADDENDUM:
I downloaded gmp-6.2.1 source, and found __gmpz_clear here:
gmp-6.2.1\gmp-h.in
#define mpz_clear __gmpz_clear
__GMP_DECLSPEC void mpz_clear (mpz_ptr);
"gmp-h.in" is a template used by the project's "autoconf", to generate the libGMP source files for the specified target environment.
Which, in turn, means:
The project you started out with (in your original question) wasn't configured for MinGW
... and ...
You didn't run "configure" correctly when you tried building from source.
SUGGESTION:
Try building libGMP from source again. DELETE everything, re-extract from the libGMP tarball, and carefully follow the INSTALL instructions:
./configure
make
make check <= VERY IMPORTANT!!
make install
I'm curious about your build environment (Windows? Linux?), compiler (exact MinGW version) and target (if you're building on a Windows workstation, do you want to run your GMP app as a Windows .exe)?
I'm trying to build a 3rd party C++ library from source, and it depends on Boost. In the very last step when building, I got errors like this:
[ 90%] Linking CXX executable Shannon_RNASeq_Cpp
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o: In function `command_line_for_find_rep(int, char**, Shannon_C_setting&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >&)':
/home/lambda/Shannon_Cpp_RNA_seq/src/main.cpp:320: undefined reference to `boost::program_options::options_description::options_description(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)'
I searched other questions on StackOverflow (e.g. Boost Program Options link error), and initially thought that it was caused by the different compilers used to build the non-header part of Boost, so I downloaded the source of Boost 1.68.0 and built it in my personal directory using the same compiler I used to build the 3rd party library (the compiler is gcc 8.2.0), and from the error message, I can tell that C++11 standard was used (you can see cxx11 in the error message), so it can't be the case that compiler not supporting C++11 is causing the trouble, as supposed previously (e.g. undefined reference to boost::program_options in xubuntu). To build Boost with a custom compiler (the default compiler of the server is terribly outdated), I followed the instructions here.
Some further search reveals that this is a linking problem. The 3rd party library must be built by CMake, and I followed the instruction in an answer to a previous question (How to link C++ program with Boost using CMake), by adding this line to CMakeLists.txt in the root directory of the 3rd party library:
target_link_libraries(Shannon_RNASeq_Cpp ${Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE})
However, the same problem persists. I checked the file CMakeCache.txt, and confirmed that the desired compiler is used and Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE points to the libboost_program_options.so in the directory where I put Boost 1.68.0 (the server has other older versions of Boost). I then used make VERBOSE=1 to check the bash commands invoked while building the library. The command doesn't sound wrong; the Boost program_options library has been linked; here's the command from make VERBOSE=1:
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/Shannon_RNASeq_Cpp.dir/link.txt --verbose=1
It's referring to something in link.txt, and here's what I found there:
/home/lambda/mylibs/bin/c++ -g -rdynamic CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/run_tasks.cpp.o -o
Shannon_RNASeq_Cpp lib_shannon/libmulti_graph_handler.a
lib_shannon/libcontig_graph_handler.a lib_shannon/libprimary_lib.a
-lboost_program_options lib_shannon/libsparse_flow_handler.a
-lglpk lib_shannon/libseq_graph_handler.a -lpthread
-lboost_system -Wl,-Bstatic -lmetis -Wl,-Bdynamic -lboost_filesystem
-lboost_program_options
So yes, Boost program_options has been linked (-lboost_program_options). I wonder if this is something wrong with program_options, since all errors that occurred at this stage are from program_options; I also linked to 2 other Boost compiled libraries, namely filesystem and system, and they do not appear in any error message I saw here.
I solved this problem myself (see my answer below), but new to CMake (and my only experiences with C++ is Rcpp), I don't know why it worked. Can someone please explain why switching to a static library worked? Also, when CMake linked to the default version of Boost on the server, it also by default used the .sos rather than the .as, even though the .as are available. Is there any way to tell CMake to use the .as rather than the .sos? Are there other solutions?
What I did was to change all the .sos in CMakeCache.txt into .as, like I changed libboost_program_options.so into libboost_program_options.a, and this error went away. Then the command from make VERBOSE=1 became:
/home/lambda/mylibs/bin/c++ -g -rdynamic CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/run_tasks.cpp.o
-o Shannon_RNASeq_Cpp lib_shannon/libmulti_graph_handler.a
lib_shannon/libcontig_graph_handler.a lib_shannon/libprimary_lib.a
-Wl,-Bstatic -lboost_program_options lib_shannon/libsparse_flow_handler.a
-Wl,-Bdynamic -lglpk lib_shannon/libseq_graph_handler.a -lpthread
-Wl,-Bstatic -lboost_system -lmetis -lboost_filesystem -lboost_program_options -Wl,-Bdynamic
I'm currently learning OpenCL. Now, when I want to compile my program, I get an error with this command:
g++ -Wall -l OpenCL main.cpp -o main
The errors are mostly undefined references, because the library is not linked, I think (nevertheless I will post the error code at the end).
But with this command everything works fine:
g++ -Wall main.cpp -o main -l OpenCL
So my question is, what do I have to do, to use the -l Flag in front of the command?
(The Background is: I want to use Netbeans to compile my programm and when i add the flag under -> properties -> build -> C++ Compiler -> additional options, it will put in in the Position, shown in the first command)
Thanks in advance for your help
Here's the error code:
/tmp/ccmKP4oI.o: In function `cl::detail::ReferenceHandler<_cl_context*>::release(_cl_context*)':
main.cpp:(.text._ZN2cl6detail16ReferenceHandlerIP11_cl_contextE7releaseES3_[_ZN2cl6detail16ReferenceHandlerIP11_cl_contextE7releaseES3_]+0x14): undefined reference to `clReleaseContext'
/tmp/ccmKP4oI.o: In function `cl::detail::ReferenceHandler<_cl_command_queue*>::release(_cl_command_queue*)':
main.cpp:(.text._ZN2cl6detail16ReferenceHandlerIP17_cl_command_queueE7releaseES3_[_ZN2cl6detail16ReferenceHandlerIP17_cl_command_queueE7releaseES3_]+0x14): undefined reference to `clReleaseCommandQueue'
/tmp/ccmKP4oI.o: In function `cl::Platform::getInfo(unsigned int, std::string*) const':
main.cpp:(.text._ZNK2cl8Platform7getInfoEjPSs[_ZNK2cl8Platform7getInfoEjPSs]+0x22): undefined reference to `clGetPlatformInfo'
/tmp/ccmKP4oI.o: In function `cl::Platform::get(std::vector<cl::Platform, std::allocator<cl::Platform> >*)':
main.cpp:(.text._ZN2cl8Platform3getEPSt6vectorIS0_SaIS0_EE[_ZN2cl8Platform3getEPSt6vectorIS0_SaIS0_EE]+0x41): undefined reference to `clGetPlatformIDs'
main.cpp:(.text._ZN2cl8Platform3getEPSt6vectorIS0_SaIS0_EE[_ZN2cl8Platform3getEPSt6vectorIS0_SaIS0_EE]+0xb4): undefined reference to `clGetPlatformIDs'
collect2: error: ld returned 1 exit status
Order of [most] arguments to g++ is very important.
Libraries should go last (at least after source and object files). You can't really change that.
The -l should preferably be glued to the library name:
g++ -Wall main.cpp -o main -lOpenCL
# ^^^ glue the -l to the library name
You probably want to also pass -g (in addition of -Wall) to the compiler to get a debuggable binary. Use the gdb debugger.
As James Kanze commented, you might want to replace -g with -ggdb if using specifically gdb.
With g++ (and generally under Unix), -l specifies a source of
input (either a .a or a .so), and input is processed in
order. When the input is a static library (a .a file), it
will be scanned for objects which resolve undefined references;
if it is a .so, there aren't any object files in it, but it
will still only be taken into consideration if it resolves some
undefined symbol.
When you put the -l before any object files, there are no
undefined symbols yet, so nothing will be incorporated into the
program.
I am working with a large C++ code that has been developed over a few years. I have added to the code and have been successfully running it on Mac OX 10.7.5. However, it is very slow and I now want to run it on a cluster (g++ (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]). I am not very experienced as far as C++ and I'm a complete newbie as far as dealing with compilation / linking.
I am unable to get past a linking error related to a "jpeg" library and would be very grateful for any help. I have the library code installed in a directory where my code resides, but my understanding is that it is also available from the compiler.
There is a lot of error output, so I won't post it all. Here is the first part:
/data/place/number/account/program/libraries/libfile_intel.a(Grid.o):
In function program::Grid<double>::SaveToJPG(char const*,
int, bool, bool) const':
Grid.cpp:(.text._ZNK3program20GridIdE9SaveToJPGEPKcibb[program::Grid<double>::SaveToJPG(char
const*, int, bool, bool) const]+0x499): undefined reference to
jpeg_std_error(jpeg_error_mgr*)'
Grid.cpp:(.text._ZNK3program20GridIdE9SaveToJPGEPKcibb[program::Grid::SaveToJPG(char
const*, int, bool, bool) const]+0x4b5): undefined reference to
`jpeg_CreateCompress(jpeg_compress_struct*, int, unsigned long)'
What I have tried:
When I did a search in Google on this problem, I discovered from an old forum post that the jpeg library compiles in C. This apparently causes the C++ compiler to mess up names. I'm not clear on what this means, but I followed advice to add:
extern "C" {
#include "jpeglib.h"
}
in all of the files in my jpeg directory that contain "#include "jpeglib.h." I wrote, "jpeglib.h" because, as I mentioned, I have a directory containing the jpeg code. However, I did also try to use the jpeg code provided by default and I got a message saying it is not available on the cluster compiler.
In my makefile, I have checked all of my includes and paths. These do not seem to be the problem. Also, I have similar paths and includes for other libraries in other directories, and they're fine.
I also added: -lstdc++ to my list of compiler options (from advice on another old forum post). It had zero effect.
One weird observation I have made is that when I do "make" of the entire code (several libraries within various directories), the jpeg library does not make unless I specifically go into its directory and do "make" there. As I said, the code is way too big to post this to demonstrate that I have no path errors. I am pretty sure I don't, but this behavior seems very odd.
If anyone is still with me after this long post, I would be very grateful for any tips. Thanks.
Edit:
In my makefile, here is what i have for compiling/linking:
CC = g++
OPTIONS = -O3 -fpermissive -w -DSAMG_UNIX_LINUX -DSAMG_LCASE_USCORE
-DNDEBUG -DCSP_WITH_SAMG_SOLVER
Edit 2: result of Svens's advice
I did:
find /usr /opt -iname libjpeg*so*
And got:
/usr/lib/libjpeg.so.62
/usr/lib/libjpeg.so.62.0.0
/usr/lib64/libjpeg.so.62
/usr/lib64/libjpeg.so.62.0.0
/usr/lib64/libjpeg.so find:
/usr/lib64/mozilla': Permission denied find:
/usr/lpp/mmfs/gui/runtime': Permission denied
me#login1:/data/place/number/account/program/support_libraries/jpeg>
cd ../../libraries/
me#login1:/data/place/number/account/program/libraries> find $HOME
-iname libjpeg*so*
If my understanding is correct, the library exists and has been found in the "libraries" directory, which is where I expect. My main makefile that links all the libraries has an include path to the directory where the jpeg library resides. The other libraries in that directory are found. What is the "permission denied" doing?
Edit 3: result of Sven's advice to change the makefile options:
Here's what I changed:
First added "-lgems3k -L/usr/lib -ljpeg" to my LIBS (the libraries). This leads to the errors below.
Then added (leads to same error as original):
OPTIONS = -O3 -fpermissive -w -DSAMG_UNIX_LINUX -DSAMG_LCASE_USCORE -DNDEBUG -DCSP_WITH_SAMG_SOLVER -/usr/lib/libjpeg.so.62
-L/usr/lib -ljpeg /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc
/data/place/number/account/program/libraries/lib1_intel.a(Grid.o): In
function `program::Grid::SaveToJPG(char const*, int, bool,
bool) const':
Grid.cpp:(.text._ZNK3program20GridIdE9SaveToJPGEPKcibb[program::Grid::SaveToJPG(char
const*, int, bool, bool) const]+0x499): undefined reference to
`jpeg_std_error(jpeg_error_mgr*)'
and so on...
Following up on the comments: are you sure you installed libjpeg? Run
find $HOME -iname libjpeg\*so\*
to find the libjpeg you need to link to. This command will most likely yield several results.
You can simply take the first line of this output and append it to your compilation command, but leave out the "-ljpeg" suggested above.
If it does not give any output at all, you don't have libjpeg installed in your home. So either
install libjpeg
disable the part of the code that needs it if you don't need it either
extend your search,
like
find /usr /opt -iname libjpeg\*so\*
... and try with one of the libjpeg installations on the system.
EDIT (after libjpeg was found on the system):
Try appending
/usr/lib/libjpeg.so.62
to the compile command (the OPTIONS variable in your Makefile). If that doesn't work, try
-L/usr/lib -ljpeg
(Edit by Mats:)
Also make sure EVERY place where #include "jpeglib.h" is covered by extern "C" { ... }. It may make sense to replace these with a c++ wrapper include, which does the addition of extern "C" { ... } in one place, and then just include "wrapped_jpeglib.h" in the relevant places.
(End Edit by Mats)
I have a problem, i want to compile my application with static linking of mysql connector.
My command line:
g++ -o newserver stdafx.cpp ... -lboost_system -lboost_thread
-lpthread -lmysqlcppconn -static /usr/lib/libmysqlcppconn-static.a -std=c++0x
But i have error:
/usr/bin/ld: cannot find -lmysqlcppconn
/tmp/ccxpOfdZ.o: In function `IsEqualsDns(unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
Server.cpp:(.text+0x356e): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: ld returned 1 exit status
How can i fix this?
Thanks!
Where is the library libsqlcppconn.a or libsqucppconn.so
(static or dynamic)? The compiler is looking for it, and
doesn't find it.
Presumably, this is the same library as
/usr/lib/mysqlcppconn-static.a. If so, just drop the
-lmysqlcppconn. Or just use -lmysqlcppconn-static (no
spaces), and forget about the /usr/lib/libmysqlconn-static.a.
With a name like that, there shouldn't be a corresponding .so,
which means that g++ will link it statically, even without the
-static. You only need the -static if there is both
a libmysqlconn-static.so and a libmysqlconn-static.a in the
same directory.
With regards to the second error (which is just a warning, but
will cause problems if you try to run the linked program on
other machines, or even after an upgrade of your machine): if
you use -static anywhere in your command line (as you
currently do), then it applies to all files linked afterwards.
Including the system libraries, which you don't want to link
statically. My guess is that the -static isn't necessary (see
above); if it is, place it immediately before the library you
want to link statically, and place a -dynamic immediately
after (so that any following libraries, including the system
libraries, will be dynamically linked).
You could try g++ -static YOUR ARGUMENTS.
If you are coming from a Windows platform, linking against Boost can give a few surprises. The typicall Boost installation (e.g. after ./b2 install) will make both dynamic and static libraries and put them in the same directory. Typically, the two library forms only differ in their extension (.so or .a).
Windows supports auto-linking, which basically means that library files contain some flags in their first few bytes indicating whether they are for dynamic or for static linking. On Linux platforms, this is not the case and the linker gets confused which file to load (since you don't provide the extension of the library name). Therefore, you need to tell your linker which form of linking you want.