When compiling with the experimental LLVM3.5 libraries link the following link errors appear:
/usr/lib/llvm-3.5/lib/libLLVMSupport.a(Process.o): In function
llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x85b):
undefined reference tosetupterm'
/usr/lib/llvm-3.5/lib/libLLVMSupport.a(Process.o): In function
llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x87a):
undefined reference totigetnum'
/usr/lib/llvm-3.5/lib/libLLVMSupport.a(Process.o): In function
llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x888):
undefined reference toset_curterm'
/usr/lib/llvm-3.5/lib/libLLVMSupport.a(Process.o): In function
llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x890):
undefined reference todel_curterm'
The link command line was generated with llvm-config, so why is this failing?
llvm-config is not adding the link option for the Terminfo library. Add
-ltinfo
To link in the library and all should be well.
Add llvm-config --system-libs in link option
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 am relatively new to TCL and I am trying to execute a C++ program using SWIG on Windows 10. Using command prompt. I am not using Visual Studio
I am basically trying to run r_cpp using C++ MinGW from TCL
C:\swigwin-3.0.12\Examples\r\class>swig -c++ -tcl example.i`
C:\swigwin-3.0.12\Examples\r\class>g++ -c example.cxx
C:\swigwin-3.0.12\Examples\r\class>g++ -c example_wrap.cxx -I/Tcl/include/tcl8.6
C:\swigwin-3.0.12\Examples\r\class>g++ -shared example.o example_wrap.o -o example.dll
example_wrap.o:example_wrap.cxx:(.text+0x981): undefined reference to `_imp__Tcl_ResetResult'`example_wrap.o:example_wrap.cxx:(.text+0x995): undefined reference to `_imp__Tcl_SetObjResult'`example_wrap.o:example_wrap.cxx:(.text+0x9b9): undefined reference to `_imp__Tcl_SetErrorCode'
example_wrap.o:example_wrap.cxx:(.text+0x9cf): undefined reference to `_imp__Tcl_ResetResult'
example_wrap.o:example_wrap.cxx:(.text+0x9f3): undefined reference to `_imp__Tcl_SetErrorCode
example_wrap.o:example_wrap.cxx:(.text+0xa1e): undefined reference to `_imp__Tcl_AppendResult'
example_wrap.o:example_wrap.cxx:(.text+0xa3c): undefined reference to `_imp__Tcl_NewStringObj'
collect2.exe: error: ld returned 1 exit status
Can someone please help me on this??
Should I make changes to my Makefile.in in the folder?????
Its been a while since I've done C but I would think that you are not linking in the static/shared library that has the functions that g++ is complaining about. In this case the tcl library something like libTclXX.dll. I'm not too familiar with command lines on windows but something like -llibtclXX.dll -L path_to_tcllib could be added. If I recall correctly tcl does provide a stub library for you to link staticially your extension then at runtime the shared library can be use to resolve the functions... so something like -llibtclstubs.dll . look in your installed lib directory for actual names of these libraries.
So I have a very sample code for trying to decode a FFMPEG video stream.
My problem is avcodec does not want to link, to do so I made a clean installation of Ubuntu 13.04. I have build ffmpeg from source following the guide here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
I just want to compile my file. Note that my ubuntu does not have any implementations or header files for avcodec. The command line I use is:
gcc -I/home/USER/ffmpeg_build/include -L/home/USER/ffmpeg_build/lib -lavcodec -o test.exe Downloads/auv/src/dronerosvideo/src/ar2.cpp
/tmp/ccKTprFq.o: In function `fetch_and_decode(int, int, bool)':
ar2.cpp:(.text+0x36e):
undefined reference to `avcodec_register_all'
ar2.cpp:(.text+0x378):
undefined reference to `av_log_set_level'
ar2.cpp:(.text+0x382):
undefined reference to `avcodec_find_decoder'
ar2.cpp:(.text+0x3b1):
undefined reference to `avcodec_alloc_context3'
ar2.cpp:(.text+0x3d6):
undefined reference to `avcodec_open2'
ar2.cpp:(.text+0x46d):
undefined reference to `av_init_packet'
ar2.cpp:(.text+0x50a):
undefined reference to `avcodec_decode_video2'
ar2.cpp:(.text+0x534):
undefined reference to `av_free_packet'
/tmp/ccKTprFq.o:(.eh_frame+0x13): undefined reference to
`__gxx_personality_v0'
collect2: error: ld returned 1 exit status
Just for a sane test if I remove the -L argument compiler says:
/usr/bin/ld: cannot find -lavcodec
Which means that the linker finds the library in /home/USER/ffmpeg_build/lib. Also if we check the library for implementation it exists:
nm ffmpeg_build/lib/libavcodec.a | grep "register_all"
0000000000000000 T avcodec_register_all
Also as advised since it is C++ I have exten "C" around the include of the library.
At this point I'm falling out of any ideas at all, why exactly compilation fails?
First, it is C++, so you'll need to use g++ not gcc so that the C++ standard library gets linked. This should get rid of undefined reference to '__gxx_personality_v0'.
Then, the order of libaries to link is actually important.
You'll need to specify a library after the object (or source or other library) using it.
Putting it together, a command line like this works (in my tests):
g++ -o test.exe -I$HOME/ffmpeg/include test.cc -L$HOME/ffmpeg/lib -lavcodec
(Actually, depending on how ffmpeg was built, you might need other libraries as well, like pthreads or libx264)
If you got pkg-config installed, it might be possible to just ask that it for proper clags:
# Since you didn't install ffmpeg to a known location, tell pkg-config about that location.
export PKG_CONFIG_PATH=$HOME/ffmpeg/lib/pkgconfig
g++ -o test.exe $(pkg-config -clags libavcodec) test.cc $(pkg-config -libs libavcodec)
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.