How to set library search path for 64-bit libraries for g ++ in Ubuntu?

Trying to compile something for 64-bit unix using Ubuntu. As a disclaimer, I just started using linux and gcc a few days ago, so I'm still learning my way. Anyway, getting the following error:

/home/myuser/myproject/myfile.cpp-00-0037: undefined reference to `clock_gettime '

A quick google shows that I need the -lrt option to communicate with librt.a. So I check my command line (formatted for reading, different file names and deletes file name lists):

/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 

Hm. Looks like -lrt already exists, maybe I don't have librt.a? Unable to find all files, I have / usr / lib / x 86_64-linux-gnu / librt.a. Probably g ++ does not look in the right place. Therefore, in the above command line, I will replace -lrt with / usr / lib / x 86_64-linux-gnu / librt.a and bingo! he compiles and links the fine. Unfortunately, this is an automated tool, and I need it to work on many computers and not be able to make assumptions about the location of librt.a, so I really need it to work with -lrt. So how do I set the local library search path? The first attempt changes the environment variable LD_LIBRARY_PATH, but apparently (from what I can say due to more search queries), this is ignored on ubuntu, and instead I have to mess with .conf files in the / etc / ld file .so.conf.d /, however I already look like I already have x86_64-linux-gnu.conf with the following lines:

 # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu 

From my reading of this paragraph it is clear that this should be all that I need. The view is stuck in where to go from here ...

+4
source share
1 answer

Answering my own question, in case anyone else has a problem. It turns out the correct librt.a is linking, but the linker is very sensitive to the linking order. Setting -lrt and -lpthread at the end of the group fixes the problem.

+1
source

Source: https://habr.com/ru/post/1383505/


All Articles