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)
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 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.
Ok, newb question here.
I'm trying to compile simple_xy_wr.f90 -- a netCDF example program -- using gfortran on Ubuntu, and I must be doing something pretty silly; I don't have much experince compiling Fortran.
First, I've got the libnetcdf-dev package installed, which includes files like
/usr/lib/libnetcdf.a
/usr/lib/libnetcdff.a
/usr/include/netcdf.mod
So, I've tried to compile the code with (various command like)
f95 -o xy -I/usr/include/ -L/usr/lib/ -lnetcdff -lnetcdf simple_xy_wr.f90
and I get the following output
/tmp/ccE6g7sr.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccE6g7sr.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
I think that I'm including the right libraries. E.g. it seems that __netcdf_MOD_nf90_strerror should be there:
$ nm /usr/lib/libnetcdff.a | grep __netcdf_MOD_nf90_strerror
000000000004a100 T __netcdf_MOD_nf90_strerror
What am I doing wrong?
(FWIW, a few relevant references I've looked at are below.
undefined reference using netcdf library
Compiling problems with gfortran and NETCDF
Compiling and Running Fortran Programs - a basic guide
)
Ordering of object files and archives on the linker command line is very important on Unix systems since the default linker behaviour is to search for symbol definitions only in archives that follow the object file or archive, where an unresolved reference was found, referred to single pass linking.
This means that if your code references __netcdf_MOD_nf90_strerror, then the archive that contains the definition of this symbol (libnetcdff.a) must appear after the list of object files from your program. libnetcdff.a itself references symbols from the C library libnetcdf.a, hence it must be linked after libnetcdff.a. So the correct link order is:
/tmp/ccE6g7sr.o libnetcdff.a libnetcdf.a
where /tmp/ccE6g7sr.o is the temporary object file that the assembler produces from the compiled source file. The correct command line to compile your code is then:
f95 -o xy -I/usr/include/ simple_xy_wr.f90 -lnetcdff -lnetcdf
In this case the linker is not called directly, rather the compiler does it. GCC compilers pass all link-related things in the same order to an intermediate utility called collect2 which then calls the actual linker ld.
Note that if shared object versions of the netCDF library archives are also present (i.e. there are libnetcdff.so and libnetcdf.so), then the linker would prefer them to the static archives (unless static linking is enabled with the -static option) and the final link phase would be handled to the run-time link editor (RTLD) (/lib64/ld-linux-x86-64.so.2 on Ubuntu). In this case the same command line as in your question would actually succeed without link errors, despite the fact that both libraries are positioned before the code that references them, as the missing symbol references would be resolved by the RTLD while it is loading the executable file.
In Ubuntu 12.10, the order of the libraries is the trick (as Hristo suggested):
angelv#palas:~$ gfortran -o xy -I/usr/include/ -L/usr/lib/ -lnetcdf -lnetcdff simple_xy_wr.f90
/tmp/ccj95anF.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccj95anF.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
angelv#palas:~$ gfortran -o xy -I/usr/include/ simple_xy_wr.f90 -L/usr/lib/ -lnetcdf -lnetcdff
angelv#palas:~$ ./xy
0 12 24 36
*** SUCCESS writing example file simple_xy.nc!
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.