Ld Cannot Find an Existing Library

ld cannot find an existing library

The problem is the linker is looking for libmagic.so but you only have libmagic.so.1

A quick hack is to symlink libmagic.so.1 to libmagic.so

usr/bin/ld: cannot find -lnameOfTheLibrary

If your library name is say libxyz.so and it is located on path say:


then to link it to your program:

g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog

ld from other source cannot find a library

I had riscv32-unknown-elf- but then i installed make -j$(nproc) build-riscv32i-tools and the issue went away. Thanks @KamilCuk

ld not finding existing library

You should try

main: main.o param.o dmotifs.o ssa.o
$(FC) $^ $(LFLAGS) $(LIBS) -o main

instead of

main: main.o param.o dmotifs.o ssa.o
$(FC) $(LFLAGS) $(LIBS) -o main $^

because linker flags should come last, otherwise it will silently discard the libraries because there are no unresolved symbols at the time the flags are processed.

Linker can't find existing library

Strangely these do also have the 32 suffix... whatever, probably for easier porting.

To maintain source compatibility with programs that use functions like LoadLibrary or GetModuleHandle: Keep them working without having to alter the strings that go into these functions.

If you look at the errors, it tells you it can't find the libraries ….lib. Note the .lib suffix. Now if you look at your linker command line you specified them as -lOpenGL32.lib and -lGLu32.lib which is wrong. The parameters passed to the -l parameter are the library names without standard filename prefixes or suffixes. The correct -l parameters would be -lopengl32 and -lglu32.

GNU ld cannot find library which is there

LD_LIBRARY_PATH is for runtime linker/loader (same effect could be achieved with ldconfig ). What you need is the -L flag:


on the compiler command line.


And - thanks to @bjg for reminding me - you can use LIBRARY_PATH if you don't want to mess with compiler options.

Related Topics

Leave a reply