I have a structure of code like this:
project_dir/
source1.c
subdir/
source2.c
The Makefile calls subdir/Makefile, so that the file subdir/source2.c is compiled in this way:
gcc -g -someoptions source2.c
and symbols in GDB link to source2.c instead of subdir/source2.c (with the result that GDB can not find symbols in source files). How should I write a Makefile or what options to use in gcc to get symbols using the relative path to the project main directory (or eventually the absolute path)?
I can not use:
cd .. && gcc -g -someoptions ../subdir/source2.c
because I would have to change references to header files in all files in subdir.
Your question is platform-specific (e.g. on Linux GDB should just work(TM), so I assume you are not on Linux).
One option is to build like this:
gcc -g ${PWD}/source2.c -o ...
Another option is to use GDB dir command to add ${TOP}/project_dir/subdir to the list of directories that GDB will search for sources.
Related
I have two projects: mylib and myproj
mylib compiles into a shared object.
myproj uses mylib.
I linking myproj using:
g++ -L../../mylib/Release myproj.o -lmylib
That works fine on my development machine.
On another machine, mylib.so is located in /usr/local/lib. Therefore there is no need for -L.
It compiles fine without the -L.
But, once I compile it with the same command (with the -L), it responds with
g++: error: ../../mylib/Release: No such file or directory
I would like myproj to compile on both machines with the same command.
Is there a way to make it ignore non existing directories?
It doesn't seem to care whether a full path doesn't exist, it complains only for relative paths.
You want to use Makefiles as often as you can since they make things a lot easier. In a defined Makefile you could check for the directory first. It could be sth like this:
all:
if [ -d "mylib" ]; then
g++ -L../../mylib/Release myproj.o -lmylib
else
g++ myproj.o -lmylib
fi
Of course you can use Variables like CC, etc. This is just a basic example.
I tried to use gcc command to link a static library, but it didn't work.
If you want to use the -l flag command to link your application like so:
gcc t.c -L. -lt1.a -o t
Then your .a archive needs to have a filename of libt1.a not just t1.a.
When using -lsome_name to link in a library, the linker will look for a file named libsomename.so or libsomename.a
If you do not want to rename your .a archive, you can also just do
gcc t.c t1.a -o t
also, in the future please don't post an image of your code or commands, just copy paste it as text into your post
Libraries in POSIX environments (like Linux and OSX) are usually named in the pattern lib<name of library>.a. When you link with the library you either use the -l option and only use <name of library> and the linker will automatically add the lib prefix and .a suffix. Or you don't use the -l option and istead give the whole file-name verbatime.
Since you don't use the standard naming scheme for the libraries, you can't use the -l option and instead have to explicitly use the library file, similar to
$ gcc ... t1.a
If you want to use the -l option you have to name your library libt1.a and only use t1 when linking:
$ gcc ... -L. -lt1
I have an issue regarding the linking of a shared library with a non-standard naming convention under several directories. I need the generated executable to search for the shared library within the executables current location, but cannot find a command line parameter to force this behavior.
To demonstrate this behavior all that is required is a shared library that is under a directory.
gcc -shared mylib.c -o some/dir/mylib.so
gcc main.c -o main -Lsome/dir -l:mylib.so
The executable main gives the following ldd output:
ldd main
some/dir/mylib.so (0xf76e2000)
The output that I require is:
ldd main
mylib.so => some/dir/mylib.so (0xf7700000)
This output can be created if the library is named conventionally as libmylib.so rather than mylib.so like so:
mv some/dir/mylib.so some/dir/libmylib.so
gcc main.c -o main -Lsome/dir -lmylib
This also drops the path some/dir in the ldd listing as required.
I have investigated the use of rpath, and command line options for both the ld and gcc but I am unable to find a satisfactory solution. The strict requirements of a non-standard name and directory structure cannot be changed easily in this case.
My question is how can I force the dependency of the library to be relative to the current directory rather than absolute as in the second ldd through gcc command line options.
Thank you for your time, I hope I have explained the problem reasonably.
Jon.
Try to add soname in your shared library:
$ gcc -shared mylib.c -o some/dir/mylib.so -Wl,-soname=mylib.so
$ gcc main.c -o main -Lsome/dir -l:mylib.so
$ LD_LIBRARY_PATH=some/dir:$LD_LIBRARY_PATH ldd main
mylib.so => some/dir/mylib.so (0x00007fa7a4fd6000)
There's a magic variable you can pass to rpath to do this: $ORIGIN. See man ld.so for details.
I think in your case, the command should look like this (untested):
gcc main.c -o main -Lsome/dir -lmylib -Wl,-rpath,'$ORIGIN/some/path'
Note that you mustn't let the shell expand $ORIGIN as a shell variable.
BTW, this was the first Google hit for "rpath relative".
I have a fortran program that calls some dependent .o object files. I would like to be able to step across files when debugging, is this possible?
the compilation routine goes something like this:
gfortran -g -o analyze.x analyze.o active.o analysis.o angles.o attach.o basefile.o beeman.o bicubic.o
where analyze.x is the executable. All of the .o files have been compiled using the -g flag as well.
When i do (gdb) break main and then attempt to step through the program, most of the subroutines take place in the object files. I was wondering if it is possible to be able to step through the object file code as well.
This will work only if the object files linked into the executable have debug information in them, i.e. have been compiled with the -g option. So, this should work:
# Compile all Fortran and C files with debug info
gfortran -g -c *.f90
gcc -g -c *.c
# Link everything together
gfortran -g -o myexe *.o
This question already has answers here:
How to link using GCC without -l nor hardcoding path for a library that does not follow the libNAME.so naming convention?
(3 answers)
Closed 3 years ago.
I have to link my code to a shared library without the lib prefix. (say, foo.so) The first problem is -l option does not find the file. So I tried directly including this file to the last compilation like this:
gcc a a.o /PATH/TO/FOO/foo.so
But in this case, a is hard linked to foo.so as an absolute path as seen in "ldd a":
/PATH/TO/FOO/foo.so
In the final deployment both files would end up being in the same folder, so this should be normal link, not the absolute path. How can I do this?
Assuming an ELF platform, if you can rebuild foo.so:
- the best fix is to simply name it libfoo.so
- the next best fix is to set SONAME on it:
gcc -Wl,-soname,foo.so -o foo.so foo.o
when you later link with:
gcc -o a.out a.o /path/to/foo.so
only the SONAME will be recorded as a dependency, not a full /path/to/foo.so.
If you can't rebuild foo.so, then do this:
rm -f foo.so && ln -s /path/to/foo.so foo.so &&
gcc -o a.out a.o ./foo.so && rm -f foo.so
-Wl,-rpath,. --> to use current directory for searching lib files. (even if not found in compilation, ok at run-time)
instead of -llibrary --> use library.so.
This seems to work correctly. Hope anyone finds this useful.