The context is the following: I am trying to compile InkscapeLite from sources in Linux Mint. At the end of the compilation, the last command is (some .o and .a files are replaced with "...", because the command is very long):
gcc -g -O2 -o inkscape --export-dynamic inkscape.o inkscape-stock.o ... ./.libs/libinkscape.al dialogs/libspdialogs.a ... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 /usr/lib/i386-linux-gnu/libcairo.so -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libart_lgpl_2.so /usr/lib/i386-linux-gnu/libxml2.so /usr/lib/i386-linux-gnu/libpopt.so -lpng -lXft -L/usr/lib/i386-linux-gnu /usr/lib/i386-linux-gnu/libfreetype.so -lz -Wl,--rpath -Wl,/usr/lib/i386-linux-gnu -Wl,--rpath -Wl,/usr/lib/i386-linux-gnu
It fails with error: gcc: error: unrecognized option '--export-dynamic'
What I have done is to replace --export-dynamic with -export-dynamic, just for test (notice, I am not C/C++ programmer and know nothing about GCC or any other C compiler) and executed the command manually in the console. The compilation ended without errors and the program works, but it misses almost all toolbar and menu icons (only some common icons are there as open/save/copy/paste...)
Is it because of this problem option --export-dynamic or there is some different problem in the sources?
BTW, the same program works normally in the Puppy Linux distributions.
It seems the building scripts issue. --export-dynamic is a linker (ld in Unixes) option which could be useful in your case but it isn't gcc frontend option. All GCC versions I see have -rdynamic flag which causes passing of --export-dynamic to linker. So you can fix this with your own means (e.g. simply try to rename the option in makefile/etc.) and/or report the issue to maintainers.
Use gcc -rdynamic or -Wl,--export-dynamic (the -Wl tells to send the next suboption to ld ...)
Related
Somehow my CUDA binary build process has been messed up. All of the .cu files compile nicely to .o files, but when I try to link, I get:
CMakeFiles/tester.dir/tester_intermediate_link.o: In function `__cudaRegisterLinkedBinary_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37':
/tmp/tmpxft_00006b54_00000000-2_tester_intermediate_link.reg.c:7: undefined reference to `__fatbinwrap_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37'
Now, I have not used compute_52 anywhere. My nvcc command-line is:
/usr/local/cuda/bin/nvcc -M -D__CUDACC__ /home/joeuser/src/my_project/src/kernel_specific/elementwise/Add.cu -o /home/joeuser/src/my_project/CMakeFiles/tester.dir/src/kernel_specific/elementwise/tester_generated_Add.cu.o.NVCC-depend -ccbin /usr/bin/gcc-4.9.3 -m64 --std c++11 -D__STRICT_ANSI__ -Xcompiler ,\"-Wall\",\"-g\",\"-g\",\"-O0\" -gencode arch=compute_35,code=compute_35 -g -G --generate-line-info -DNVCC -I/usr/local/cuda/include -I/opt/cub -I/usr/local/cuda/include
and my link line is:
/usr/bin/g++-4.9.3 -Wall -std=c++11 -g some.o files.o here.o blah.o blahblah.o bar.cu.o baz.cu.o -o bin/myapp -rdynamic -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL -Wl,-rpath,/usr/lib:/usr/local/cuda/extras/CUPTI/lib64
I'll note I have separate compilation enabled, and do not seem to have skipped my intermediate link phase.
Why is this happening?
CUDA has two compilation modes, relocatable and static.
The relocatable mode is required for some configurations-which we will not get into now.
If you want to compile in relocatable mode -rdc=true, you'll need the Cuda device runtime library.
Which is located in the file cudadevrt.lib.
On some instances, supplying -lcudadevrt as a command line switch to the CUDA linker does the job, but on e.g. MSVC, you'll also need to specify cudadebrt.lib as a link dependency.
Well, I'm not sure why I'm seeing missing references to Compute 5.2 calls, but adding -lcudadevrt to the end of the link command makes the error go away.
I am compiling using arm-linux-gnueabi-g++ version 4.7.3.
I have the arm-linux-gnueabi libraries installed at location:
/usr/arm-linux-gnueabi/lib, it contains libdl.a, libdl.so, libdl.so.2,
and libdl-2.19.so.
libdl.so links to libdl.so.2 which links to libdl-2.19.so.
I am trying to link against the dl library (see command string below), but I always get the undefined reference errors.
arm-linux-gnueabi-g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -L/usr/arm-linux-gnueabi/lib -lComms -lConsole -lUtilities -ldl
../../work/libUtilities.so: undefined reference to `dlsym'
../../work/libUtilities.so: undefined reference to `dlopen'
collect2: error: ld returned 1 exit status
If I compile using g++ 4.8.2 using the following commend then my program compiles, links, and executes fine.
g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -lComms -lConsole -lUtilities -ldl
Obviously it can't find the libdl.so library; I thought that by adding the path to the location of the appropriate library by using the -L flag would fix the problem, but it didn't.
What am I missing with the ARM compiler command?
Well, I found the answer, I needed -Wl,--no-as-needed flag before the -ldl. I had run across this flag before I asked the question, but apparently mistyped it because it hadn't worked for me.
I don't understand why the flag is needed, but the code does finish linking now.
A SO user here says that it has to do with recent (2013 as of the user's post) versions of gcc linking to --as-needed.
I have study makefile projec. I am using the gnu gcc and as linker, I use the gcc with the following argument:
linkerCmdLine=$(exe) -Wl,--start-group -nostdlib -Map=test_mapfile.map -l:libc.a -l:libgcc.a -l:libm.a -Wl,--end-group -o $(output)
During the linking process, the linker does not use all of this flags:
The flag -Map=test_mapfile.map is not used.
Why??
There is a project settings file and in this one is also stored the linker settings.
\u201ClinkerCmdLine\=$(exe) -Wl, --start-group -nostdlib -Map\=./99_output/PUZ_GPF.map --gc-sections -l\:libc.a -l\:libgcc.a -l\:libm.a -Wl,--end-group -o $(output)\u201D
How must I store the settings correct?
Edited:
With the the map file works fine, but I have actually problem with the linker file. I use only the following flag:
"linkerCmdLine=$(exe) -Wl, --script=C:/workspace/test_project/test_linker_file.ld -static -o $(output)”
I get this error in the console window:
arm-none-eabi-gcc.exe: error: unrecognized command line option '--script=C:/workspace/test_project/test_linker_file.ld'
I don't understand why, because the map file and the .ld file belong to the linker flags.
The -Wl, prefix only passes the current argument, with commas separating linker arguments. So in order to pass -z defs, you would use -Wl,-z,defs.
This mechanism only works for true flags, i.e. when the position in the command line is irrelevant. The -l parameters are not flags, and the gcc compiler driver collects them into a separate list and passes them in a single block.
So this technique doesn't work for the exact commandline you want. On the other hand, the -nostdlib inhibits the -lc -lgcc -lm that would be the default.
Normally there is a provision in the gcc specs (the script for the compiler driver) to use --start-group and --end-group around the standard libraries when linking statically (which appears to be what you want to do).
So I think that
linkerCmdLine=$(exe) -Wl,-Map=test_mapfile.map -static -o $(output)
should work for your case.
OS: Windows 7
Compiler: MinGW
IDE: Code::Blocks
I just installed Gtkmm on my computer in the folder C:/gtkmm/ and set up an example program. When I compiled it, it gave the error "gtkmm.h: No such file or directory"
I tried setting the PATH variable to C:/gtkmm/include and C:/gtkmm/gtkmm-2.4, but neither worked. Then I tried using #include "C:/gtkmm/include/gtkmm-2.4/gtkmm.h" and that just gave a ton of errors saying that it doesn't know where a few dozen files are.
I've also heard that you need to put pkg-config gtkmm-2.4 --cflags --libs in the compiler options, but that didn't work either.
What am I doing wrong and how do I fix it?
pkg-config is a helper function for adding cflags and lib paths to the compiler line.
What you will need to do is add the libraries and cflags path to the compiler line. I am not 100% sure how to do that in code::blocks., though
In ubuntu 11.04, you need all these to compile even a simple gtkmm program:
Libs (pkg-config --libs gtkmm-2.4:
-pthread -lgtkmm-2.4 -latkmm-1.6 -lgdkmm-2.4 -lgiomm-2.4 -lpangomm-1.4 -lgtk-x11-2.0 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
cflags paths (pkg-config --clfags gtkmm-2.4):
-I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gio-unix-2.0/ -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/gtk-2.0 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/lib/gtk-2.0/include -I/usr/include/gdk-pixbuf-2.0
Basically you would have to change every instance of /usr/include/ and /usr/lib/ to c:\path-to-library\
I am not sure how much of the above you need with MinGW, but with GCC on Linux, dropping any of them makes gtkmm programs not compile. Hope that at least puts you on the right path.
What do you mean with PATH variable? The global windows search PATH for executables? That would be wrong.
You need to look in your IDE for Include search path or header search path or something like that.
Does that pkg-config command work for you when you execute it on the command line? Such a pkg-config when used on a unix system is enclosed in backticks ` which causes it to be substituted by it's output. Don't know if your IDE can do that but if it works from the command line you have at least a list of all includes needed.
Use autotools C++ project. You need only edit two files configure.ac and Makefile.am.
Add this line to configure.ac
PKG_CHECK_MODULES([GTKMM], [gtkmm-3.0])
and these lines to Makefile.am
program_CPPFLAGS = $(GTKMM_CFLAGS)
program_LDADD = $(GTKMM_LIBS)
I'm trying to link to a static library, libcovis.a. Everything looks fine but I still have
undefined reference to `CoViG_PublicDemo::MoInS::reset()'
I checked that the name exists in the library
$nm libcovis.a | grep reset
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
I'm using linking arguments -L/path/to/libcovis.a -lcovis
What am I doing wrong ?
Edit:
The error might be something else, if do
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
It works !
But when I'm in KDevelop using cmake, I doesn't work anymore. I use
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
CMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
The only difference I can see is that the paths are absolute and not relative, but if he couldn't find the libs, he would say it...
There are two different issues there, the first of which is the simplest, you have used the wrong compiler options. The -L option tells the linker to also look in the directory when looking for a library. The -l tells it to link the specific library. To link you would then use:
g++ -o test test.o -L/path/to -lcovis
or
g++ -o test test.o -l/path/to/libcovis.a
To force static linking if the same library is present as a dynamic library in the same directory.
The second potential issue is that the order of static libraries in the linker command line does matter, so that might also be an issue if there is a dependency on different static libs.
g++ -o test tests.o -ldependent -lprovider
The linker will process the libraries in order as they are in the command line, and from each static lib it will only pull those symbols that are required (with as much information as the linker has at that time). In the command line above, the linker will extract from dependent the symbols it needs for test.o, and that might in turn add new undefined symbols to the program (the dependencies of dependent). When it processes provider it will fill in those symbols. If the order was reversed in the command line, the symbols that are required by dependent but not by test.o would not be added to the executable, as the linker does not know that those symbols will be needed when processing provider.
Should the arguments be like -L/path/to/ -lcovis?
Besides, object files should be placed before libs, for example
g++ obj1.o obj2.o -L/path/to/ -lcovis.
If you see the link succeeding in one context but not another, I suspect the problem may be caused by the order in which the link operation is executed as the linker will discard symbols in a library if they're not needed at the point in which the library is referenced.
Here is a link explaining: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
I've run into similar situations in the past the linking order was found to be the cause of the problem.