0

I'm running make and ld will not find libraries that I have verified to exist using dnf provides '*/libpthread.so' for example. I get the following error code:

g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o 
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lm
/bin/ld: cannot find -ldl
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: bayescan_2.1] Error 1

These libraries all are found in /usr/lib64 on my chair's computing cluster. However the ld.so.conf file does not include a path that only goes to /usr/lib64 and I don't have admin permissions to create a new .conf file in /etc/ld.so.conf.d/.

Is there any way I can force make to search for the libraries in /usr/lib64?

Here is the actual Makefile in question:

# BayeScan makefile

bayescan_2.1: start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o 
    g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o 

start.o: start.cpp errors.cpp anyoption.h global_defs.h
    g++ -fopenmp -c start.cpp errors.cpp 

beta.o: beta.cpp global_defs.h
    g++ -fopenmp -c beta.cpp 
      
dirichlet.o: dirichlet.cpp global_defs.h
    g++ -fopenmp -c dirichlet.cpp 

RJupdates.o: RJupdates.cpp global_defs.h
    g++ -fopenmp -c RJupdates.cpp 

MHupdates.o: MHupdates.cpp global_defs.h
    g++ -fopenmp -c MHupdates.cpp 

likelihood.o: likelihood.cpp global_defs.h
    g++ -fopenmp -c likelihood.cpp 

read_write.o: read_write.cpp errors.cpp global_defs.h
    g++ -fopenmp -c read_write.cpp errors.cpp 

anyoption.o: anyoption.cpp anyoption.h 
    g++ -fopenmp -c anyoption.cpp 

clean: 
    rm *.o bayescan_2.1

EDIT:

Turns out ld was trying to find static libraries with the -static flag. Removing this flag from the Makefile fixed the issue.

  • Use the -L option to specify library search path. – kiner_shah Jul 21 '22 at 10:47
  • 2
    Libraries generally needs to be put *after* the object files that needs them on the command line. – Some programmer dude Jul 21 '22 at 10:50
  • Does this answer your question? [Why does the library linker flag sometimes have to go at the end using GCC?](https://stackoverflow.com/questions/9417169/why-does-the-library-linker-flag-sometimes-have-to-go-at-the-end-using-gcc) – stark Jul 21 '22 at 11:00
  • If that were the problem, there would be errors like "undefined reference to pthread_create", not "cannot find -lpthread". – Thomas Jul 21 '22 at 11:28

1 Answers1

2

Simply add -L/usr/lib64 to the link command. See Directory Options in the GCC manual:

-Ldir

Add directory dir to the list of directories to be searched for -l.

If you can't or don't want to edit the Makefile, you can supply additional search directories through an environment variable

LIBRARY_PATH

The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cannot find them using GCC_EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).

For example, run this in your shell before invoking make:

$ export LIBRARY_PATH="$LIBRARY_PATH:/usr/lib64"
Thomas
  • 174,939
  • 50
  • 355
  • 478
  • I guess I'm confused exactly how to do this. Do I edit the Makefile itself? – Miles Anderson Jul 21 '22 at 11:01
  • Yes, that should be fine, if it's not generated by something. But I'll edit with an alternative approach. – Thomas Jul 21 '22 at 11:05
  • I should have given a better question. For example I already edited the first module as such: `g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o -L/usr/lib64` and `g++ -L/usr/lib64 -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o` and neither fixed the error. – Miles Anderson Jul 21 '22 at 11:07
  • Alright, I tried the export command as well and still get the error for some reason. – Miles Anderson Jul 21 '22 at 11:22
  • 1
    Maybe `/usr/lib64` is absent from the configuration with good reasons, such as being for a different platform than `g++` is building for? Try `--verbose` to see some more details about what's going on. – Thomas Jul 21 '22 at 11:26
  • The library path does include /usr/lib64 from the verbose output. Same error though. Strange. I guess it must just be something with the cluster that I can't figure out. – Miles Anderson Jul 21 '22 at 11:41
  • @MilesAnderson If you run the command `file /usr/lib64/...` for one of the libraries that you attempt to build with, what does it say? Is the library matching your system? – Some programmer dude Jul 21 '22 at 11:56
  • @MilesAnderson Also, are you attempting to link with static libraries (library files ending with `.a`) or dynamic libraries (ending with `.so`)? – Some programmer dude Jul 21 '22 at 11:58
  • Ah ok. They show as being symbolic links to relative paths that don't exist. `/usr/lib64/libpthread.so: symbolic link to ../../lib64/libpthread.so.0` What should I do then? Also they are all dynamic libraries as far as I know. – Miles Anderson Jul 21 '22 at 12:03
  • 2
    Sounds like your servers are broken and misconfigured. No compilation flag will fix that. – Sam Varshavchik Jul 21 '22 at 12:06
  • Damn. Well you all did a great job. Thanks a million for the help. Definitely not the answer I wanted lol. I'll see if I can get in touch with the system admin. – Miles Anderson Jul 21 '22 at 12:11