I am taking an existing project and updating it to use Clang. I have version 3.9 installed and while I can compiler fine I am getting an error when linking. I am using the linker provided by LLVM and compiling to an ARM target from Windows.
The linker error I get is: symbol not DefinedRegular or Shared
I'm not exactly sure what is wrong and Googling around doesn't seem to produce many results. The linker isn't telling me which symbol or anything like that. Thus the error message is pretty vague.
Any help would be great. Thanks!
EDIT:
The Linker Command: Running it on it's own produces the same cryptic error as running it via the makefile
C:/LLVM/bin/ld.lld.exe --sysroot=../common/arm-sysroot/lts-12.04 C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_arm.o C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_armplatform.o C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_rtc.o C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/executive.o C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/executivemain.o C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/processregistry.o ../build/linux2-arm-release-obj/exec_client.o ../build/linux2-arm-release-obj/procstatus.o ../build/linux2-arm-release-obj/statusLogClient.o ../build/linux2-arm-release-obj/xmlLogClient.o ../build/linux2-arm-release-obj/statusLogBuf.o ../build/linux2-arm-release-obj/xmlLogBuf.o ../build/linux2-arm-release-obj/engLogBuf.o ../build/linux2-arm-release-obj/logBuf.o ../build/linux2-arm-release-obj/statusLogMsg.o ../build/linux2-arm-release-obj/xmlLogMsg.o ../build/linux2-arm-release-obj/engLogMsg.o ../build/linux2-arm-release-obj/logMsg.o ../build/linux2-arm-release-obj/statusLogFile.o ../build/linux2-arm-release-obj/xmlLogFile.o ../build/linux2-arm-release-obj/engLogFile.o ../build/linux2-arm-release-obj/engLogTable.o ../build/linux2-arm-release-obj/engLogEntry.o ../build/linux2-arm-release-obj/treatmentLogMsg.o ../build/linux2-arm-release-obj/treatmentHistoryMsg.o ../build/linux2-arm-release-obj/flowsheetMsg.o ../build/linux2-arm-release-obj/alertsAlarmsMsg.o ../build/linux2-arm-release-obj/logFile.o ../build/linux2-arm-release-obj/notifierSharedMemory.o -L../build/linux2-arm-release-obj -lutil -lplutodb -losi -lutil -lsyserror -lxml2 -lsqlite3 -lssl -lgcrypt -lcrypto -lpthread -lrt -luuid -L ../common/arm-sysroot/lts-12.04/lib/arm-linux-gnueabi -L ../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi -o ../build/linux2-arm-release-image/executive
symbol not DefinedRegular or Shared
Here is the linker output via the makefile:
symbol not DefinedRegular or Shared
make: *** [executive] Error 1
Here is the verbose linker output via the makefile:
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_arm.o
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_armplatform.o
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/exec_rtc.o
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/executive.o
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/executivemain.o
C:/Software/b2/D1_Common/software/application/base/executive/buildfiles/linux2-arm-release-obj/processregistry.o
../build/linux2-arm-release-obj/exec_client.o
../build/linux2-arm-release-obj/procstatus.o
../build/linux2-arm-release-obj/statusLogClient.o
../build/linux2-arm-release-obj/xmlLogClient.o
../build/linux2-arm-release-obj/statusLogBuf.o
../build/linux2-arm-release-obj/xmlLogBuf.o
../build/linux2-arm-release-obj/engLogBuf.o
../build/linux2-arm-release-obj/logBuf.o
../build/linux2-arm-release-obj/statusLogMsg.o
../build/linux2-arm-release-obj/xmlLogMsg.o
../build/linux2-arm-release-obj/engLogMsg.o
../build/linux2-arm-release-obj/logMsg.o
../build/linux2-arm-release-obj/statusLogFile.o
../build/linux2-arm-release-obj/xmlLogFile.o
../build/linux2-arm-release-obj/engLogFile.o
../build/linux2-arm-release-obj/engLogTable.o
../build/linux2-arm-release-obj/engLogEntry.o
../build/linux2-arm-release-obj/treatmentLogMsg.o
../build/linux2-arm-release-obj/treatmentHistoryMsg.o
../build/linux2-arm-release-obj/flowsheetMsg.o
../build/linux2-arm-release-obj/alertsAlarmsMsg.o
../build/linux2-arm-release-obj/logFile.o
../build/linux2-arm-release-obj/notifierSharedMemory.o
../build/linux2-arm-release-obj\libutil.a
../build/linux2-arm-release-obj\libplutodb.a
../build/linux2-arm-release-obj\libosi.a
../build/linux2-arm-release-obj\libutil.a
../build/linux2-arm-release-obj\libsyserror.a
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libxml2.so
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libsqlite3.so
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libssl.so
../common/arm-sysroot/lts-12.04/lib/arm-linux-gnueabi\libgcrypt.so
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libcrypto.so
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libpthread.so
../common/arm-sysroot/lts-12.04/lib/arm-linux-gnueabi/libpthread.so.0
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi/libpthread_nonshared.a
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\librt.so
../common/arm-sysroot/lts-12.04/usr/lib/arm-linux-gnueabi\libuuid.so
symbol not DefinedRegular or Shared
make: *** [executive] Error 1
Related
I'm trying to use LLVM to build a compiler backend, but I've gotten mired in linker errors. Currently all I attempt to do is include LLVMContext.h (I'm doing the IBM tutorial), but this gives me the following linker error:
$ g++ -o compiler *.o -L/home/jakob/llvm2/lib/*.a -lantlr4-runtime
BayesBaseListener.o:(.data.rel+0x0): undefined reference to `llvm::DisableABIBreakingChecks'
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'compiler' failed
make: *** [compiler] Error 1
Any idea how to configure LLVM correctly so this doesn't happen?
The option -L is to add a path that the linker uses to search for libraries. The option -l (lower-case L) is to tell the linker to link with a specific library.
For your case though, if you want to link with all static libraries in a specific location, just list the library files as input files:
g++ -o compiler *.o /home/jakob/llvm2/lib/*.a -lantlr4-runtime
Note that I don't use the -L option.
I'm struggling to compile SDL_Gfx with cygwin.
The configure script worked without issues.
Here's the last makefile command:
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -I/usr/local/include/SDL2 -Dmain=SDL_main -no-undefined -release 1.0 -version-info 0:1:0 -o libSDL2_gfx.la -rpath /usr/local/lib SDL2_framerate.lo SDL2_gfxPrimitives.lo SDL2_imageFilter.lo SDL2_rotozoom.lo -L/usr/lib -lcygwin -lSDL2main -lSDL2
libtool: link: warning: library `/usr/lib/libSDL2.la' was moved.
And here's the linker "warning" message.
*** Warning: linker path does not have real file for library -lSDL2main.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libSDL2main and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libSDL2main.a
If i try to ignore this, I'm getting this error when I try to use the library inside my application:
In function `pixel':
/usr/local/lib/SDL2_gfx-1.0.1/SDL2_gfxPrimitives.c:75: undefined reference to `SDL_RenderDrawPoint'
/usr/local/lib/SDL2_gfx-1.0.1/SDL2_gfxPrimitives.c:75:(.text+0x11): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `SDL_RenderDrawPoint'
UPDATE: I tried to switch compiler to use mingw64 instead of cywin. I'm having a similar issue, I think this is related to libtool since I can compile an external programs with similar c/l flags without issues.
I don't know what I can try I ran out of ideas, please help.
Thank you
I re-organized the directory tree of an existing project, making relevant Sconscript changes, and in so-doing I introduced the following linker error:
/bin/ld: note: '__cxa_free_exception##CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line
/usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
I found this thread and if I follow that advice and attempt to be explicit about the system libs it just kicks the can down the road (the ensuing error will be about libm and so on with other system libs).
Since this compiles fine without my reorganization, what could have been done to scons where it no longer links to system libs?
Nowhere in the existing SConstruct/Sconscript fileset is there any reference to linking against any of the system libs. This was automagically done by scons, but now that I have rearranged a few subprojects, I encounter the above error.
The libpath and rpath both include the following:
'/usr/lib64',
'/usr/lib64/mysql',
'/usr/local/lib',
Linker Command
gcc -o build/debug/icln/src/foo/fooCert/build/scons/fooCertFromFiles -Wl,-rpath=/usr/lib64 -Wl,-rpath=/usr/lib64/mysql -Wl,-rpath=/usr/local/lib -Wl,-rpath=/ws/build/debug/icmn/src/common -Wl,-rpath=../../../../engine/build/scons -Wl,-rpath=../../../../foo/build/scons -Wl,-rpath=../../../../kb/build/scons -Wl,-rpath=../../../../bar/build/scons -Wl,-rpath=../../../../tables/build/scons -Wl,-rpath=../../../../utils/build/scons -L/usr/lib64 -L/usr/lib64/mysql -L/usr/local/lib -Lbuild/debug/icmn/src/common -L/ws/icmn/src/common -Lbuild/debug/icln/src/engine/build/scons -Lsrc/engine/build/scons -Lbuild/debug/icln/src/foo/build/scons -Lsrc/foo/build/scons -Lbuild/debug/icln/src/kb/build/scons -Lsrc/kb/build/scons -Lbuild/debug/icln/src/bar/build/scons -Lsrc/bar/build/scons -Lbuild/debug/icln/src/tables/build/scons -Lsrc/tables/build/scons -Lbuild/debug/icln/src/utils/build/scons -Lsrc/utils/build/scons -lcengine -lbar -lfoo -lkb -lcutils -lCommon -ltables -lglog -lboost_date_time -lboost_serialization -lboost_system -lboost_filesystem -lmongoclient -lboost_thread -lpthread -lmysqlcppconn -lmysqlclient
Update: I noticed the call to build the final binary was to gcc, and not g++. I am still trying to determine why it suddenly switched to gcc instead of g++, but I think this is heading towards root cause.
How does scons determine whether to invoke CC vs CXX?
Solved: So because of the re-organization I performed, a call to Glob() was resolving to an empty list since I had changed the path to where the source files are.
The fix: I needed to update the Glob call to use new path to the source (the Sconscript and source files no longer co-reside in the same directory as they did before).
BEFORE
source = Glob('*.cc')
AFTER
source = Glob('../../src/*.cc')
The following is my current environment
Boost version - 1.55
Cmake - 2.8
Ubuntu - 12.04
g++ - 4.8
MPI - 1.8.1
BLAS/LAPACK - Intel MKL
When I compile my Boost MPI code in the above settings, I am getting the following error.
`.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_mpi.a(broadcast.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_3mpi9exceptionEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_mpi.a(broadcast.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(cmdline.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_17bad_function_callEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(cmdline.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(value_semantic.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_15program_options16validation_errorEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(value_semantic.o)
`.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(convert.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_program_options.a(convert.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED1Ev[_ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED1Ev]' of /usr/lib/x86_64-linux-gnu/libboost_iostreams.a(gzip.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_9iostreams10gzip_errorEED5Ev]' of /usr/lib/x86_64-linux-gnu/libboost_iostreams.a(gzip.o)
collect2: error: ld returned 1 exit status
make[2]: *** [factor] Error 1
make[1]: *** [CMakeFiles/factor.dir/all] Error 2
make: *** [all] Error 2
Browsing the internet I figured the following solutions and none of them works.
Having the latest of all the software compiler, libraries, cmake etc. I have the latest. But I still have the problem.
Include -fexceptions and -fno-use-linker-plugin. I am still getting the error with my current linker command as follows.
/usr/bin/mpicxx -fexceptions -fno-use-linker-plugin CMakeFiles/factor.dir/factor.cpp.o CMakeFiles/factor.dir/factor_jobs.cpp.o -o factor -rdynamic -L/home/ramki/libraries/armadillo-4.300.0/usr/lib -L/home/ramki/intel/mkl/lib/intel64 /usr/lib/x86_64-linux-gnu/libboost_mpi.a /usr/lib/x86_64-linux-gnu/libboost_program_options.a /usr/lib/x86_64-linux-gnu/libboost_iostreams.a -lboost_serialization -lboost_iostreams -lboost_program_options -lboost_mpi -llapack -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lpthread -lm -lz -larmadillo factorization/libfactorization.a -Wl,-rpath,/home/ramki/libraries/armadillo-4.300.0/usr/lib:/home/ramki/intel/mkl/lib/intel64
Change the order of the linking libraries - Even this didn't help.
Let me know what is the mistake and how to resolve this error.
When I uninstalled Boost1.43 to move to Boost1.55, some files of Boost1.43 were left in /usr/lib directory as well. The new libraries of Boost1.55 are installed in /usr/lib/x86_64-linux-gnu. While linking if /usr/lib is in the path before /usr/lib/x86_64-linux-gnu, then there is a change of boost1.43 libraries getting mixed up with Boost1.55. I deleted the older Boost1.43 files from /usr/lib and these problems got resolved. Remember to include /usr/lib/x86_64-linux-gnu in the lib path during compilation.
I'm trying to build a specific program on Ubuntu 12.04 64 bit.
The program needs to be compiled 32 bits.
I installed the ia32-libs and gcc-multilib packages.
I managed to compile it on 3 different computers, but on this one, it fails with a weird error.
for some reason, libm.so is not picked up correctly, or something is wrong with the library.
This is the actual compilation line that fails as it was extracted from the Makefile.
gcc -o x86_32_obj/foo x86_32_obj/foomain.o -m32 -fPIC -fno-stack-protector -lc -lgcc -lm -lpthread -lrt -lstdc++ ../libfoo/lib/./libfii.x86_32.a
This is the output
/usr/bin/ld: ../libfoo/lib/./libfoo.x86_32.a(NK_Meas.o): undefined reference to symbol 'expf##GLIBC_2.0'
/usr/bin/ld: note: 'expf##GLIBC_2.0' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [foo] Error 2
make: *** [foo] Error 2
I have seen errors such as this in relation to the linking order. It may be possible to address the error by placing the libm linking directive at the very end of your linking configuration.
These interdependencies are very much system dependent, which is probably why the same command works on other systems.
Found the problem.
Apparently, the library file I was linking against was compiled using a different version of GCC.
I don't know how exactly it's related, but once I replaced the gcc compiler to the one used with the library it worked.