I'm trying to link an open source project that uses GSL and I get undefined references in libgsl. I'm using eclipse and I've added -lgslcblas -lgsl to the libraries setting. What am I missing?
g++ -L/home/erwin/ochack/bin/opencog/spatial -L/home/erwin/ochack/bin/opencog/persist/sql -L/home/erwin/ochack/bin/opencog/guile -L/home/erwin/ochack/bin/opencog/util -L/home/erwin/ochack/bin/opencog/persist/xml -o "ocserver" ./opencog/server/Agent.o ./opencog/server/BaseServer.o ./opencog/server/BuiltinRequestsModule.o ./opencog/server/CogServer.o ./opencog/server/CogServerMain.o ./opencog/server/ConsoleSocket.o ./opencog/server/DataRequest.o ./opencog/server/ExitRequest.o ./opencog/server/HelpRequest.o ./opencog/server/ListRequest.o ./opencog/server/LoadModuleRequest.o ./opencog/server/LoadRequest.o ./opencog/server/NetworkServer.o ./opencog/server/Request.o ./opencog/server/SaveRequest.o ./opencog/server/ServerSocket.o ./opencog/server/ShutdownRequest.o ./opencog/server/SleepRequest.o ./opencog/server/SystemActivityTable.o ./opencog/server/UnloadModuleRequest.o ./opencog/atomspace/Atom.o ./opencog/atomspace/AtomSpace.o ./opencog/atomspace/AtomSpaceAsync.o ./opencog/atomspace/AtomSpaceImpl.o ./opencog/atomspace/AtomSpaceInit.o ./opencog/atomspace/AtomTable.o ./opencog/atomspace/AttentionBank.o ./opencog/atomspace/AttentionValue.o ./opencog/atomspace/ClassServer.o ./opencog/atomspace/CompositeTruthValue.o ./opencog/atomspace/CountTruthValue.o ./opencog/atomspace/FixedIntegerIndex.o ./opencog/atomspace/Handle.o ./opencog/atomspace/HandleEntry.o ./opencog/atomspace/HandleIterator.o ./opencog/atomspace/HandleSeqIndex.o ./opencog/atomspace/HandleSet.o ./opencog/atomspace/HandleTemporalPair.o ./opencog/atomspace/HandleTemporalPairEntry.o ./opencog/atomspace/HandleToTemporalEntryMap.o ./opencog/atomspace/ImportanceIndex.o ./opencog/atomspace/IndefiniteTruthValue.o ./opencog/atomspace/Link.o ./opencog/atomspace/LinkIndex.o ./opencog/atomspace/NameIndex.o ./opencog/atomspace/Node.o ./opencog/atomspace/NodeIndex.o ./opencog/atomspace/NullTruthValue.o ./opencog/atomspace/PredicateIndex.o ./opencog/atomspace/SimpleTruthValue.o ./opencog/atomspace/SpaceServer.o ./opencog/atomspace/StatisticsMonitor.o ./opencog/atomspace/StringIndex.o ./opencog/atomspace/TLB.o ./opencog/atomspace/TargetTypeIndex.o ./opencog/atomspace/Temporal.o ./opencog/atomspace/TemporalEntry.o ./opencog/atomspace/TemporalMap.o ./opencog/atomspace/TemporalTable.o ./opencog/atomspace/TemporalToHandleSetMap.o ./opencog/atomspace/TimeServer.o ./opencog/atomspace/Trail.o ./opencog/atomspace/TruthValue.o ./opencog/atomspace/TypeIndex.o ./opencog/atomspace/VersionHandle.o ./opencog/atomspace/ZMQMessages.pb.o -lboost_filesystem -lpersist -lsmob -lgslcblas -lgsl -lboost_signals -lboost_thread -lxml -lutil -lSpaceMap -lzmq -lboost_system -lprotobuf
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zher2k'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_strsv'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zdotc_sub'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_dtrsm'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zhemm'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_sgemv'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_strmm'
etc...
I found the solution: apparently the order of the libraries is important: -lgsl -lgslcblas works.
Potentially, there are lots of things that could be wrong here.
Have you made sure that you've added the libraries properly in Eclipse? For instance, you shouldn't specify -lgsl in Paths and Symbols -> Libraries. Eclipse adds the preceding -l itself so all you specify is gsl.
Have you added the library paths in the build variant that you're actually trying to run? You may, for instance, have specified library paths only for the Debug variant when you're trying to get a Release variant build going.
Alternatively, (and this is really just a guess), it's reasonably common for scientific libraries to allow you to use an external version of BLAS. Sometimes their configuration settings even insist on external BLAS as a default. Does passing -lcblas as a link option help out with these errors?
Related
Sory my english is bad.
I'm using visual code, my project is c++, -L./libs/curl/lib include only libcurl.a, that is static lib
When I build project with this link option, everything is ok:
LDFLAGS = -static -L./libs/curl/lib -lcurl -lssl -lcrypto -lsqlite3 -lpthread -ldl -lz
But when I use this link option:
LDFLAGS = -L./libs/curl/lib -l:libcurl.a -l:libssl.a -l:libcrypto.a -l:libsqlite3.a -l:libpthread.a -l:libdl.a -l:libz.a
I got this error:
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libpthread.a(pthread_create.o): In function `allocate_stack':
/build/glibc-2ORdQG/glibc-2.27/nptl/allocatestack.c:526: undefined reference to `_dl_stack_flags'
/build/glibc-2ORdQG/glibc-2.27/nptl/allocatestack.c:652: undefined reference to `_dl_stack_flags'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libpthread.a(elision-lock.o): In function `do_set_elision_enable':
/build/glibc-2ORdQG/glibc-2.27/nptl/../sysdeps/unix/sysv/linux/x86/elision-conf.c:67: undefined reference to `_dl_x86_cpu_features'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libpthread.a(nptl-init.o): In function `__pthread_initialize_minimal_internal':
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:294: undefined reference to `_dl_cpuclock_offset'
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:429: undefined reference to `_dl_pagesize'
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:438: undefined reference to `_dl_pagesize'
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:454: undefined reference to `_dl_init_static_tls'
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:456: undefined reference to `_dl_wait_lookup_done'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libpthread.a(nptl-init.o): In function `__pthread_get_minstack':
/build/glibc-2ORdQG/glibc-2.27/nptl/nptl-init.c:475: undefined reference to `_dl_pagesize'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dlopen.o): In function `dlopen':
(.text+0x5): undefined reference to `__dlopen'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dlclose.o): In function `dlclose':
(.text+0x1): undefined reference to `__dlclose'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dlsym.o): In function `dlsym':
(.text+0x5): undefined reference to `__dlsym'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dlerror.o): In function `dlerror':
(.text+0x1): undefined reference to `__dlerror'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dladdr.o): In function `dladdr':
(.text+0x1): undefined reference to `__dladdr'
So my question is:
What difference between -static -lxyz and -l:libxyz.a link option?
does -static have implicit links to add other libs?
By default gcc or g++ will link against some standard libraries. The list of these libraries is architecture dependent, but you find libc libgcc and some others. To see the list of libraries used for the link you can add -v option. You will see the list of libraries passed to collect2. Since you are compiling for x86_64 the list will be probably (libc, libgcc and libgcc_s).
When you use the static option, you force the linker to use the static version of all the libraries, those you give with -l option and the default ones.
In the second case you give the linker the static version of your libraries, but for the other libraries it is the shared version that will be taken. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used. from https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options.
A last thing. The crt files are also different if you use static option. You can see it also with -v option.
In case you want to control exactly which library should be used there is the option nostdlib. when using this option, The compiler Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify are passed to the linker, and options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, are ignored.
I'm following this tutorial however it does not state which libaries I need to include in order to get boost to work,current options for links are:
-I/usr/include/opencv2 -I/usr/include/boost_1_55_0 -I/usr/include/boost_1_55_0/boost -O0 -g3 -Wall -c -fmessage-length=0
however this returns the following erro:
which states that it can't find asio, am I doing something wrong or was assio the wrong library to link to? Or is there any other way to find out. Note that this is my 2nd c++ project(through I have a lot of java experience) and first with the heavy use of libraries so details are somewhat required.
Removing boost/asio gave me the following errors:
make all
Building target: DisplayImage
Invoking: GCC C++ Linker
g++ -L/usr/include/opencv2 -L/usr/include/boost_1_55_0/boost -L/usr/include/boost_1_55_0 -L/usr/include/opencv2 -L/usr/lib -o "DisplayImage" ./src/Cap.o ./src/DisplayImage.o ./src/Filters.o ./src/sender.o -lopencv_imgproc -lopencv_highgui -lopencv_core
./src/sender.o: In function `__static_initialization_and_destruction_0':
/usr/include/boost_1_55_0/boost/system/error_code.hpp:222: undefined reference to `boost::system::generic_category()'
/usr/include/boost_1_55_0/boost/system/error_code.hpp:223: undefined reference to `boost::system::generic_category()'
/usr/include/boost_1_55_0/boost/system/error_code.hpp:224: undefined reference to `boost::system::system_category()'
./src/sender.o: In function `error_code':
/usr/include/boost_1_55_0/boost/system/error_code.hpp:323: undefined reference to `boost::system::system_category()'
./src/sender.o: In function `boost::asio::error::get_system_category()':
/usr/include/boost_1_55_0/boost/asio/error.hpp:224: undefined reference to `boost::system::system_category()'
collect2: ld returned 1 exit status
make: *** [DisplayImage] Error 1
Build Finished **
I use an ubuntu (x64) laptop if it matters.
Most of boost is implemented in what's called "header-only" code. Through the generous use of C++ templates, there is no actual library code to which your code needs to link. However, there are, as you've seen some actual libraries as well. Generally, the help you seek is probably here: http://www.boost.org/doc/libs/1_55_0/more/getting_started/unix-variants.html#link-your-program-to-a-boost-library
Your particular program uses the timer and system libraries and so you can probably use this command line to link your program:
g++ timer.cpp -o timer -lboost_timer -lboost_system
You can look at the bjam in boost/libs/asio/example/cpp03/tutorial/Jamfile.v2:
project
: requirements
<library>/boost/system//boost_system
<library>/boost/thread//boost_thread
<define>BOOST_ALL_NO_LIB=1
<threading>multi
<os>SOLARIS:<library>socket
<os>SOLARIS:<library>nsl
<os>NT:<define>_WIN32_WINNT=0x0501
<os>NT,<toolset>gcc:<library>ws2_32
<os>NT,<toolset>gcc:<library>mswsock
<os>NT,<toolset>gcc-cygwin:<define>__USE_W32_SOCKETS
<os>HPUX,<toolset>gcc:<define>_XOPEN_SOURCE_EXTENDED
<os>HPUX:<library>ipv6
;
You can see that they build all the tutorial steps with
-lboost_system -lboost_thread -DBOOST_ALL_NO_LIB=1
on linux
I'm attempting to compile this tutorial http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window/ with Cygwin. I'm getting the following errors:
$ g++ main.cpp -o main -lm -lgl -lglut -lglew -lglfw -lopengl32 -lglu32 -lglaux
-lodbc32 -lodbccp32
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11a0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11c8): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11f0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1394): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1661): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1696): more undefined references to `_imp___iob' follow
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: /usr/lib/gc
c/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o): bad reloc address 0x0
in section `.rdata'
collect2: error: ld returned 1 exit status
What may be causing this?
When you see unresolved symbols to _imp__, it implies you are trying to link against a library that was built to use a DLL at run-time. Technically, the problem is how the MSVC compiler mangles the import stub for __stdcall functions - it pre-fixes an underscore, which gcc is not expecting (e.g. _imp instead of imp).
cygwin/MinGW needs a little bit of extra help (either they must use a library that was compiled with gcc or the MSVC DLL-based import library must be altered). There is an article that explains this here.
However, the vast majority of the time the simpler solution is simply to link against the static linking version of your library. In the case of GLEW and glfw, they both ship with static libraries. You will need to define GLEW_STATIC and link against glew32s instead of glew. As for glfw, I am not as familiar - consult the documentation for glfw to find out how to do this.
I'm having trouble compiling some examples in a odbc sdk. After some time mingling with the library order, I somehow managed to get the number of undefined references to just a handful of them.
Sadly, I can't figure out how to get rid of the remaining ones. Here's the command that's failing:
g++ -Wall -z defs -m64 -DSIMBA -D_REENTRANT -fPIC -O0 -g -shared Common/TabbedUnicodeFileReader_Linux_x8664_debug.cpp.o Core/QSConnection_Linux_x8664_debug.cpp.o Core/QSDriver_Linux_x8664_debug.cpp.o Core/QSEnvironment_Linux_x8664_debug.cpp.o Core/QSStatement_Linux_x8664_debug.cpp.o DataEngine/QSDataEngine_Linux_x8664_debug.cpp.o DataEngine/QSMetadataHelper_Linux_x8664_debug.cpp.o DataEngine/QSTable_Linux_x8664_debug.cpp.o DataEngine/QSTableUtilities_Linux_x8664_debug.cpp.o DataEngine/QSTypeInfoMetadataSource_Linux_x8664_debug.cpp.o Common/QSTableMetadataFile_Unix_Linux_x8664_debug.cpp.o Common/QSUtilities_Unix_Linux_x8664_debug.cpp.o Main_Unix_Linux_x8664_debug.cpp.o -Wl,--no-undefined -Wl,--no-allow-shlib-undefined -Wl,--whole-archive,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaDSI_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaSupport_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libAEProcessor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libCore_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libDSIExt_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libExecutor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libParser_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaODBC_debug.a -Wl,--no-whole-archive -Wl,--soname=../Bin/Linux_x8664/libQuickstart_debug.so -L/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//ThirdParty/icu/Linux_x8664/lib -licuuc_simba64 -licudata_simba64 -licui18n_simba64 -lpthread -lm -lc -ldl -Wl,--version-script=exports_Linux.map -o ../Bin/Linux_x8664/libQuickstart_debug.so
Edit: Missing symbols
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so: undefined reference to `_dl_rtld_di_serinfo#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls_init#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__libc_stack_end#GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_get_tls_static_info#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__tls_get_addr#GLIBC_2.3'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_deallocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_argv#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__libc_enable_secure#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global_ro#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_make_stack_executable#GLIBC_PRIVATE'
Fixed:
Removing -Wl,--no-allow-shlib-undefined seemed to do the trick. The built shared library seems to work perfectly.
I had a similar issue with a completely separate application. The following compile time flag worked for me:
-B/usr/lib/gold-ld/
which i found at:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/885927
I'm using gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 I was trying to compile with lto.
You do a very common newbie mistake. you place the libraries to link with in the middle or the beginning of the command line. The linker GCC uses needs dependencies in reverse order. That means if you have an source/object file S using a function in library L, the file A has to be before the library L on the command line.
In short, put the libraries (-lm -lc -ldl) last on the command line instead.
If linker fails to resolve all referenced symbols then this can be a result of wrong order of provided libraries. If you are not sure what is the correct order then put archives in "--start-group archives --end-group" which according to ld manual will force linker to search the specified archives repeatedly until no new undefined references are created. But pay attention to a performance cost.
The OP mentioned "Removing -Wl,--no-allow-shlib-undefined" helped.
In my case I had to add the opposite:
-Wl,--allow-shlib-undefined
(Everything was working fine with an older version of GCC)
I'm working on a really old source code (compiled in Red Hat). Before it had lua-4.0.1 so I just compiled the latest lua (lua-5.1.4) and installed it in the same directory as the old one. The implementation isn't very big so there wasn't much to change except a few function names and I had to include "lauxlib.h" to get it to compile. It compiles without any problems but it gives these linking errors.
/usr/local/lib/liblua.a(loadlib.o): In function `ll_load':
loadlib.o(.text+0x19): undefined reference to `dlopen'
loadlib.o(.text+0x2a): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_sym':
loadlib.o(.text+0x52): undefined reference to `dlsym'
loadlib.o(.text+0x63): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_unloadlib':
loadlib.o(.text+0x8): undefined reference to `dlclose'
Basically all the paths are correct but I use the same flags for the compiler as the old one, I havent changed the makefile at all.
-static -lpthread -lnsl -lutil -ldl -lmysqlclient -llua -llualib -lz -lcppunit
The ldl flag is already there.
I just want to know things to try. Everything is appreciated. This is driving me insane.
Place -ldl at the end of the liner command. The order is important.
The linker searches for libraries fulfilling an unreferenced symbol only in libs which are standing more right on the command line. Your new liblua.a now uses dlopen and friends, while the older didn't. Since -ldl is left of -llua, the linker does not use libdl to link the lua references.