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.
Related
I am trying to use a couple of libraries, libglfw3-dev and libglew-dev, on an ubuntu environment but have been unable to get the linker to perform its intended purpose. I would normally use a makefile but for the purpose of debugging I have just used g++ on the CLI.
g++ -I-Iinclude -I/usr/include/GL -I/usr/include/GLFW -L/usr/lib/x86_64-linux-gnu/
I understand that I need to specify the libraries themselves with the -l flag but get an error of the form
/usr/bin/ld: cannot find -llibglfw
Here is some information about the locations of the packages (omitting irrelevancies)
root#Jake-Faptop:/usr/include/GLFW# dpkg -L libglfw3-dev
/usr/include/GLFW/glfw3.h
/usr/include/GLFW/glfw3native.h
/usr/lib/x86_64-linux-gnu/libglfw.so
root#Jake-Faptop:/usr/include/GLFW# dpkg -L libglew-dev
/usr/include/GL/glew.h
/usr/include/GL/glxew.h
/usr/include/GL/wglew.h
/usr/lib/x86_64-linux-gnu/libGLEW.so
The names of the shared libraries have been a matter of great confusion to me as it turns out they are named /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1.0 and /usr/lib/x86_64-linux-gnu/libglfw.so.3.3
---EDIT---
In light of the advice given to omit prefixes and suffixes on the library names I am still getting linker errors on the following input
g++ -Iinclude -I/usr/include/GL -I/usr/include/GLFW -L/usr/lib/x86_64-linux-gnu/ -lGLEW -lglfw src/main.cpp -o build/main
->
/usr/bin/ld: main.cpp:(.text+0x3b): undefined reference to glfwTerminate'
/usr/bin/ld: main.cpp:(.text+0x54): undefined reference to `glfwWindowHint'
/usr/bin/ld: main.cpp:(.text+0x63): undefined reference to `glfwWindowHint'
/usr/bin/ld: main.cpp:(.text+0x72): undefined reference to glfwWindowHint'
Confused.com...
Remove lib at the beginning of the names. E.g. the library's name is
libGLEW.so.2.1.0
Link it with
-lGLEW
This will link to libxGLEW.so which usually is a symlink to a versioned library like libGLEW.so.2.1.0.
-llibrary
-l library
Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)
The -l option is passed directly to the linker by GCC. Refer to your linker documentation for exact details. The general description below applies to the GNU linker.
The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L.
Static libraries are archives of object files, and have file names like liblibrary.a. Some targets also support shared libraries, which typically have names like liblibrary.so. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded.
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
I have two simple files:
runner.cpp:
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE Main
#include <boost/test/unit_test.hpp>
and test1.cpp:
#define BOOST_TEST_DYN_LINK
#ifdef STAND_ALONE
# define BOOST_TEST_MODULE Main
#endif
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE( Foo)
BOOST_AUTO_TEST_CASE( TestSomething )
{
BOOST_CHECK( true );
}
BOOST_AUTO_TEST_SUITE_END()
To compile, I'm using:
$ g++ -I/e/code/boost_1_52_0 -o runner -lboost_unit_test_framework runner.cpp test1.cpp
I get the following error:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0x8c): multiple definition of `main'
c:/pdev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.7.2/../../../libboost_unit_test_framework.a(unit_test_main.o):unit_test_main.cpp:(.text.startup+0x0): first defined here
c:/pdev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.7.2/../../../libboost_unit_test_framework.a(unit_test_main.o):unit_test_main.cpp:(.text.startup+0x14): undefined reference to `init_unit_test_suite(int, char**)'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0x52): undefined reference to `_imp___ZN5boost9unit_test9framework17master_test_suiteEv'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0xb0): undefined reference to `_imp___ZN5boost9unit_test14unit_test_mainEPFbvEiPPc'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test13test_observerD2Ev[__ZN5boost9unit_test13test_observerD2Ev]+0xe): undefined reference to `_imp___ZTVN5boost9unit_test13test_observerE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test13test_observerC2Ev[__ZN5boost9unit_test13test_observerC2Ev]+0xe): undefined reference to `_imp___ZTVN5boost9unit_test13test_observerE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test15unit_test_log_tC1Ev[__ZN5boost9unit_test15unit_test_log_tC1Ev]+0x22): undefined reference to `_imp___ZTVN5boost9unit_test15unit_test_log_tE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x88): undefined reference to `_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x136): undefined reference to `_imp___ZN5boost10test_tools9tt_detail10check_implERKNS0_16predicate_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x21d): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1ENS0_13basic_cstringIKcEE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x284): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1EPNS0_9test_caseEm'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x2a4): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1Ei'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text$_ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[__ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE]+0x1d): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24normalize_test_case_nameENS0_13basic_cstringIKcEE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text$_ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[__ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE]+0x5b): undefined reference to `_imp___ZN5boost9unit_test9test_caseC1ENS0_13basic_cstringIKcEERKNS0_9callback0INS0_9ut_detail6unusedEEE'
collect2.exe: error: ld returned 1 exit status
I'm using g++ 4.7.2 on MinGW, with boost 1.52.0.
I get the same errors when only trying to compile test1.cpp - except the "multiple main definition" one.
I perused the official documentation for quite a while, but its scarce on details regarding linking options. When I compiled the boost libs, besides unit_test_framework, I also got prg_exec_monitor and test_exec_monitor; perhaps I should link these somehow ? I tried many combinations, but all resulted in some kind of undefined reference linker error.
Complete list of boost generated libraries - I have them all in the project root:
libboost_prg_exec_monitor-mgw47-mt-1_52.a
libboost_prg_exec_monitor-mgw47-mt-1_52.dll
libboost_prg_exec_monitor-mgw47-mt-1_52.dll.a
libboost_prg_exec_monitor-mgw47-mt-d-1_52.a
libboost_prg_exec_monitor-mgw47-mt-d-1_52.dll
libboost_prg_exec_monitor-mgw47-mt-d-1_52.dll.a
libboost_test_exec_monitor-mgw47-mt-1_52.a
libboost_test_exec_monitor-mgw47-mt-d-1_52.a
libboost_unit_test_framework-mgw47-mt-1_52.a
libboost_unit_test_framework-mgw47-mt-1_52.dll
libboost_unit_test_framework-mgw47-mt-1_52.dll.a
libboost_unit_test_framework-mgw47-mt-d-1_52.a
libboost_unit_test_framework-mgw47-mt-d-1_52.dll
libboost_unit_test_framework-mgw47-mt-d-1_52.dll.a
With help from #llonesmiz, a number of issues were identified.
1. Libraries need to be specified after objects and sources which use them.
As described here:
The traditional behavior of linkers is to search for external functions from
left to right in the libraries specified on the command line. This means that a
library containing the definition of a function should appear after any source
files or object files which use it. This includes libraries specified with the
short-cut -l option, as shown in the following command:
$ gcc -Wall calc.c -lm -o calc (correct order)
With some linkers the opposite ordering (placing the -lm option before the file
which uses it) would result in an error,
$ cc -Wall -lm calc.c -o calc (incorrect order)
main.o: In function 'main':
main.o(.text+0xf): undefined reference to 'sqrt'
because there is no library or object file containing sqrt after ‘calc.c’. The
option -lm should appear after the file ‘calc.c’
2. Library paths should be explicitly specified.
If no lib paths are specified, the linker might look for the libs in a series
of default folders, thus loading a different library then intended. This is what
happened in my case - I wanted to link boost_unit_test_framework, but did not
specify a path because I assumed the linker would look in the current folder.
That's what happens at runtime, after all - if the dll is in the same folder
with the exe, it will find it.
I found it a little bit strange the linker would find the lib, since it was
named ibboost_unit_test_framework-mgw47-mt-1_52.dll. When I tried to link to
a non-existing lib, the linker complained though, so I assumed this isn't an
issue, and MinGW 's linker ignores those suffixes.
After some more research, I found this article about MinGW library paths.
The folders MinGW searches for libs can be found in the output of gcc -print-search-dirs.
The article also contains some bash magic to make sense of that output:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | grep -v '^ */'
This will print a nice list of those folders. gcc will not, by default,
look in the current directory for libs. I looked in each of them, and found the
lib that was being loaded - libboost_unit_test_framework.a, a static lib.
This brings into light another issue worth mentioning:
3. Static versus dynamic linking
I did not specify whether I want boost_unit_test_framework linked statically or dynamically.
In this case, gcc prefers dynamic linking:
Because of these advantages gcc compiles programs to use shared libraries by
default on most systems, if they are available. Whenever a static library
‘libNAME.a’ would be used for linking with the option -lNAME the compiler
first checks for an alternative shared library with the same name and a ‘.so’
extension.
(so is the extension for dynamic libraries on Unix - on Windows, the equivalent is dll.)
So, what happened is that gcc looked for libboost_unit_test_framework.dll
in all it's default folders, but couldn't find it. Then it looked for
libboost_unit_test_framework.a, and statically linked that. This resulted in
linking errors because the sources have #define BOOST_TEST_DYN_LINK, and
therefore expect to have the lib dynamically linked.
To enforce static or dynamic linking, the -Wl,-Bstatic and -Wl,-Bdynamic
linker options come into play, described here.
If I tell the linker that I want dynamic linking:
$ g++ -I/e/code/boost_1_52_0 runner.cpp test1.cpp -o runner -Wl,Bdynamic -lboost_unit_test_framework
This will fail, because the linker will not be able to find the dll.
4.Summary
The issues were:
libraries where specified before the sources which used them
the lib path wasn't specified
the type of linking wasn't specified
the name of the library was not correct
Final, working command:
$ g++ -I/e/code/boost_1_52_0 -o runner runner.cpp test1.cpp -L. -Wl,-Bdynamic -lboost_unit_test_framework-mgw47-mt-1_52
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 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?
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.