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')
Related
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 am trying to generate a c++ library using the g++ compiler. My library has another C library as dependency and I have compiled it in order to obtain the .so files.
I have the following structure:
src:
include/linux:
libcustom.a
libcustom.la
libcustom.so
libcustom.so.0
libcustom.so.0.0.0
Now, when I have all the .o files of my cpp classes, and I want to link the library, I execute the following command:
g++ -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o mylibrary.so File1.o File2.o File3.o -L./include/linux -lc++ -lutil -lm -lcustom -Wl,-rpath='$ORIGIN/include/linux' -L/usr/lib/R/lib -lR
But it throws me the error:
libcustom.so.0: cannot open shared object file: No such file or directory
I am executing the command from the src directory.
I know it could be fixed editing the LD_LIBRARY_PATH, but the idea it is someone can use my library without the need of configuring anything, so I am trying to do that with the c++'s -rpath flag.
Any idea how can I fix it, or the reason for the error?
The error message you got seems to come from the run-time loader ld.so instead of the linker ld (I know the names are confusing). You have to distinguish between finding so's at link-time and at run-time. The -L flag you give at link-time has nothing to do with localizing the library at run-time.
Your rpath=./include/linux value is not correct, because dot is not recognized by the ld as relative path. Relative searching path should be given like
-Wl,-rpath='$ORIGIN/include/linux'
where the $ORIGIN represents the folder where your executable (not mylibrary.so) locates. Make sure to use single quote and not double quote because the string $ORIGIN should be passed to the linker literally and hard coded into the executable file.
More details goes
how to link to shared lib from shared lib with relative path
ld: Using -rpath,$ORIGIN inside a shared library (recursive)
I have downloaded and build the boost libraries with
bootstrap mingw
and
b2 toolset=gcc
and the libraries are created in
C:\Boost\boost_1_57_0\stage\lib
In eclipse I have added this directory as a library path
and added the library libboost_thread-mgw49-mt-1_57 with and without the .a on the end.
the g++ line looks like
g++ "-LC:\\Boost\\boost_1_57_0\\stage\\lib" -o MyThread.exe main.o MyThread.o -llibboost_thread-mgw49-mt-1_57
and I get the error message
ld.exe: cannot find -llibboost_thread-mgw49-mt-1_57 collect2.exe: error: ld returned 1 exit status
If I add the .a it is appended to the error message as expected.
what am I doing wrong?
Specify the library without the lib prefix (which is the UNIX convention):
g++ "-LC:\Boost\boost_1_57_0\stage\lib" -pthread -o MyThread.exe main.o MyThread.o -libboost_thread-mgw49-mt-1_57
There's even a chance that (with the help of some standard convention symlinks) you could just say -lboost_thread.
PS Don't forget to use -pthread as well
My friend made OpenGL graphic engine, but he is working on Windows. I want to compile project with it.
I installed all required libs with headers, but now problem is with linking (project in Code::Blocks). I found paths for /usr/lib/libSOIL.a and /usr/local/lib/libglfw3.a, but what about:
C:\Program Files (x86)\CodeBlocks\MinGW\lib\libopengl32.a
C:\Program Files (x86)\CodeBlocks\MinGW\lib\assimp_debug-dll_win32\assimp.lib
Also, what I must modify in project file to compile it? It requires: glfw3, glm, gl3w.h, assimp, SOIL (this is what I get from .hpp files). I installed all headers (downloaded sources and make && make install)...
I tried to compile it from terminal with g++, but I don't know switches for libraries.
Current situation:
$ g++ Camera.o Entity.o Frustum.o gl3w.o Light.o Material.o Mesh.o Model.o ModelPart.o Shader.o Texture.o Utilities.o ../main.o -o main -L/usr/local/lib/libglfw3.a -lX11 -lXext -lXt -lSM -lGLU -lglut -lSOIL
/usr/bin/ld: gl3w.o: undefined reference to symbol 'glXGetProcAddress'
/usr/bin/ld: note: 'glXGetProcAddress' is defined in DSO /usr/lib/nvidia-313-updates/libGL.so.1 so try adding it to the linker command line
/usr/lib/nvidia-313-updates/libGL.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
(i added too much libraries to command line, I know)
EDIT
Added -lGL and -ldl and some problems comes out. Now, I'll trying compile it with makefile...
libopengl32 -> libGL.a
assimp -> libassimp.a ?
You gotta provide the Makefile you're compiling it with.
I am using Ubuntu and my IDE is Aptana 3.0
I am getting the following error when trying to build. The library libfcgi.a is located in /usr/local/lib/.
In the Library C++ Linker section of the project properties, I added /usr/local/lib/ to the search path and the file /usr/local/lib/libfcgi.a.
Why can I still not build?
**** Build of configuration Debug for project rtb ****
make all
Building target: rtb
Invoking: GCC C++ Linker
g++ -L/usr/local/lib -o"rtb" ./src/rtb.o -l/usr/local/lib/libfcgi.a
/usr/bin/ld: cannot find -l/usr/local/lib/libfcgi.a
collect2: ld returned 1 exit status
make: *** [rtb] Error 1
I think this may be what you want;
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o -lfcgi
-l<value> will automatically look in all folders listed with -L for a library named lib<value>.a or lib<value>.so, all you need is the '-lfcgi'.
Try "-lfcgi" instead
g++ -L/usr/local/lib -o"rtb" ./src/rtb.o -lfcgi
Your linker flag is wrong it needs to be -lfcgi and not the whole path with the "lib" prefix and the .a suffix.
You can change it by hand, or in Apatana. To do so you don't have to give him the full qualified path to your lib two times. ( You already gave him the search path, remember? ). Usually you define additional libraries just like this:
cfgi and your IDE does the rest to add it to the linker flags!
You should do
g++ -o "rtb" ./src/rtb.o -lfcgi
In the unlikely case that /usr/local/lib/ is not in your search path, you can either add that path in the command line like
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o -lfcgi
or put it in the environment variable LIBRARY_PATH before calling your compile command, e.g. with bash:
if [ -z "$LIBRARY_PATH" ];
then export LIBRARY_PATH=/usr/local/lib;
else export LIBRARY_PATH="$LIBRARY_PATH":/usr/local/lib;
fi
If you insist in giving the explicit file name, omit the -l:
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o /usr/local/lib/libfcgi.a
However I'd advise against that because it's inflexible. If the issue is that there's another, incompatible version of the library installed, it's better to make sure that the correct one comes first in the search path (or even better, make sure that the wrong one isn't in the search path at all ― maybe even by removing it from the system).
That's for the help all....really appreciate it.
Here is the solution. I had to use -lfcgi++ and I added the
g++ -L/usr/local/include/ -lfcgi++ -o"rtb" ./src/rtb.o
The above was the output from aptanta console. I tried -lfcgi and did not work. Google search lead to using -lfcgi++.