Trying to compile something for 64 bit unix using Ubuntu. As a disclaimer I only started using linux and gcc a few days ago so still learning my way around. Anyway, getting the following error:
/home/myuser/myproject/myfile.cpp:437: undefined reference to `clock_gettime'
A quick google reveals I need the -lrt option to link with librt.a. So I check my command line ( formatted for readability, different file names and I've remove lists of file names ):
/usr/bin/g++
-Wl,
--gc-sections
-fno-exceptions
-m64
-B/usr/bin
-o
"/home/myuser/myproject"
-Wl,
-Map, "/home/myuser/myproject/myproject.map"
-g
"/home/myuser/myproject/myproject.cpp.obj"
..and some more .objs..
-Xlinker
--start-group
"-lpthread"
"-lrt"
"/home/myuser/myproject/lib/mylib.a"
..and some more .as..
-Xlinker
--end-group
Hmm. Looks like -lrt is already there, maybe I don't have librt.a? Nope searching all files reveals I have /usr/lib/x86_64-linux-gnu/librt.a. I guess g++ is looking in the wrong place. So in the above command line I replace -lrt with /usr/lib/x86_64-linux-gnu/librt.a and bingo! it compiles and links fine. Unfortunately, this is an automated tool and I need this to work on many computers and can't make assumptions about the location of librt.a so I really need it to work with -lrt. So how do I set the local libary search path? First attempt is changing LD_LIBRARY_PATH environment variable but apparently ( from what I can tell from more googling ) this is ignored on ubuntu and instead I should be messing with .conf files in /etc/ld.so.conf.d/, however I already it looks like I already have x86_64-linux-gnu.conf in there with the following lines:
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
From my reading up this point it looks that should be all I need. Kind of stuck as to where to go from here...
Answering my own question just in case someone else has this problem. Turns out the correct librt.a was being linked but the linker is very sensitive to the link order. Putting -lrt and -lpthread at the end of the group fixes the problem.
Related
I am using GCC and I want to essentially read and load the stdlib/libc stuff from another location than /usr/include and /usr/lib. I tried to copy them to another place and compile it like this, but it doesn't work. I am not surprised that this naive approach didn't work, but it was worth a try.
gcc -nostdlib -nolibc -I<custompath>/include -L<custompath>/lib -xc test.c
Could someone nudge me in the right direction here?
With this command:
gcc -nostdlib -nolibc ...
you are asking GCC to not link with libc.
Of course it doesn't work (if your program is using libc functions). What did you expect?
Start by dropping these two flags. And if the result doesn't work then, tell us exactly what doesn't work (by editing your question).
See also documentation for the -sysroot option.
This is an old qustion, but i still can not find the solution.
i have library:
/usr/lib/x86_64-linux-gnu/libqca.so.2 (it is installed by package libqca2, and packager did not provide libqca.so link, nor I want to do that because i am looking for answer on all similar situations, not for qca example only)
so how can i include it without providing lib full-path-name:
g++ -L/usr/lib/x86_64-linux-gnu -lqca will not work because of .2 extension
g++ -L/usr/lib/x86_64-linux-gnu -lqca.so.2 is not allowed
g++ -L/usr/lib/x86_64-linux-gnu qca.so.2 not working too.
so seems as simple question, what is the answer.
"NO IT CAN NOT" can be the correct answer if someone with gcc/g++ knowledge can say it 100% and describe something about it... but isn't it strange that gcc has both infomations (paths to look for, and correct lib name) and can not just combine it (like it does with -l param for libs with standard naming).
Ok, I found the ANSWER my self,
it is about COLON character,
-l:libqca.so.2
answer found here on linux manuals: -l namespec ... If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a
simple and cool
I have a problem on linking static libraries..
I have checked and proceeded some methods to solve it, like.. reordering libraries or using some options..
However, All what I've done didn't work..
--
First of all, I'm quite sure it is from link error because I have checked the .a file by nm command and there was specific functions shown in error log.
So, I linked static library like below..
LOCAL_LINK_STATIC_LIBS := \
-I$(libdir)/libmicrohttpd.a\
-I$(libdir)/libcryptopp.a\
...
myprog_LDFLAGS = -lstdc++ -g -ldl -lpthread #GLIB_CFLAGS# $(LOCAL_LINK_STATIC_LIBS)
Is there other way to solve it? I really need your feedback..
Thanks for reading.
You must only supply the name with the -l option, e.g. -lmicrohttpd. The linker will add "lib" and ".a" or ".so". Use the -L option to set the search path for the libraries, e.g. -L$(libdir).
Also try using -pthread instead of -lpthread. -lpthread only links the pthread library whereas -pthread will do some additional work.
I'm a first year computer science student following a course on (amongst others) Makefiles. For our first assignment, we had to create a shared library and link against it.
I have the following setup:
A folder hw1 containing the folders app and lib.
Inside lib is a file called libmine.so, the library I want to link against.
Inside app, there are two files: test.cpp and a Makefile. The former uses the libmine library.
The Makefile is as follows (in the file itself, indentation etc. is correct):
all: test
test: test.cpp
g++ -Wall -o test -L../lib -I../lib/include test.cpp -lmine
However, when running test, I get the infamous `libmine.so: cannot open shared object file' error.
I believe this has something to do with exporting LD_LIBRARY_PATH. I have tried doing so (export LD_LIBRARY_PATH=$[very long relative path to the lib folder]), but I want to do this in my Makefile. Additionally, I don't want the path to be relative, as my teachter should be able to open the file when I send it to him (so I think it should be something like ../lib/libmine.so).
I looked at various StackOverflow posts, such as this one, but none seemed to answer this specific question (either it was a different setup or the solution simply didn't work). By the way: putting the line export LD_LIBRARY_PATH=../lib right under test: test.cpp and before the g++ command did not do anything.
Any help is much appreciated :)
when running test, I get the infamous `libmine.so: cannot open shared object file' error.
This is happening because the -L../lib argument tells the static linker where to find the library, but it doesn't tell anything to the dynamic linker (aka loader), and the problem is that the latter can't find this library.
To solve this, you can use LD_LIBRARY_PATH, but this is usually ill-advised.
What you want is something called RPATH or RUNPATH (assuming you are on a Linux or similar system):
g++ -Wall -o test -L../lib -I../lib/include test.cpp -Wl,-rpath=../lib -lmine
Additionally, I don't want the path to be relative, as my teachter should be able to open the file when I send it to him
Is your teacher going to run your binary on the same system, or on a different one? If the former, you could do this:
g++ -Wall -o test -L../lib -I../lib/include test.cpp -Wl,-rpath=/full/path/to/hw1/lib -lmine
If the latter, /full/path/to/hw1/lib may or may not be available on your teacher's machine, and you need to think about what exactly you are going to send to him.
The usual way to solve this is to package both the application and the library into a tar file:
tar cvf to-send.tar app/test lib/libmine.so
The teacher can then extract the parts of your tar file into arbitrary directory, and try to run it. To make this work, you need RPATH that is relative to the application, regardless of where the application ends up. To achieve that, you want:
g++ -Wall -o test -L../lib -I../lib/include test.cpp -Wl,-rpath='$ORIGIN/../lib' -lmine
in my homework i must use this command to compile my program:
gcc -o mtm_rentals -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG mtm_ex2.c rentals.c list.c -L -lmtm
what i can change in that line are the files im writing after -DNDEBUG. when i do this the gcc says that there are undefined references to specific functions. now those functions are declared in an .h file and are implemented in a given file called libmtm.a
i concluded that it doesnt recognize libmtm.a, but our homework task says that the -lmtm flag(which is not declared anywhere) is supposed to link libmtm.a to the program.
what am i missing here? am i supposed to implement somehow the -lmtm flag?
thank you!
You are missing a . (single dot) behind the -L.
-lmtm will link against a libmtm library, this is correct. It's not an -lmtm flag, it's a -l flag concatenated with mtm, the library you want to link against. This library is searched in some predefined paths (like /usr/lib/) and additionally in the paths given by -L. Assuming libmtm lives in your current directory, you need to add that to -L, which is done with a ..