Gcc Linker Can't Find Standard Library

GCC linker can't find standard library?

To link C++ code, you need to use the g++ command, not the gcc command.

When compiling, the gcc command knows that it's compiling C++ code because of the .cpp suffix (but it's a good idea to use the g++ command anyway).

When linking, the gcc command just sees a bunch of .o files. The g++ command differs from the gcc command in that it knows where to find the C++-specific libraries.

(The fact that the name gcc refers both to the command, which is usually used to compile C code, and the "GNU Compiler Collection" as a whole, can be a little confusing.)

Linker is unable to find standard libraries

If you write your own kernel you are on your own, that's sort of the point. You'll need to write system calls before you can write (or port) a standard library.

Add a -ffreestanding flag to tell the compiler that you don't have a standard library.

Edit: add -nostdlib to tell the linker that you don't have a standard library and -lgcc as the compiler might make calls to libgcc (this library is provided by your cross compiler). -m32 is unnecessary as your cross compiler is made with a 32 bit target

GCC linker does not link standard library

You cannot use the C library for a kernel as it is build for an existing kernel and relies on the syscalls of its target OS. Instead, you have to write a driver for keyboards and everything else you need to get characters from anywhere. getc() is a very advanced function from that point of view and you should consider making the basic functions of the kernel stable before programming anything to interact with.

By the way, you should really build a cross compiler. It has many advantages over feeding the system compiler with awkward options. After all, the kernel is meant to run on different machines, so it should be compiled for bare x86, which is what a cross-compiler does.

Keep coding this thing!
leitimmel

gcc linker (ld) can't find shared libraries

I fixed this issue using the compiler and linker switch --sysroot so the linker and the compiler both work using the arm rootfs as base directory.

usr/bin/ld: cannot find -l nameOfTheLibrary

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

/home/user/myDir

then to link it to your program:

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

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.

Why cant mingw find libraries that gcc can find?

Finally, it turned that you tried to link against libraries for an incompatible architecture:

Why can't mingw find libraries that gcc can find?

  • Either compiler are using different default options for the linker.

  • Even with same -L <path> and same LD_LIBRARY_PATH etc., the linker will skip incompatible libraries. In your case, gcc is presumably hosted by
    x86_64-linux-gnu, whereas x86_64-w64-mingw32-gcc is obviously hosted by x86_64-w64-mingw32. Both are incompatible.


  1. Try adding -I <path> to the compilation where <path> contains libavcodec/avcodec.h. Add more -I if you need more paths. Use -isystem <path> if it's supposed to be system headers. Add -v -H to the compilation to see what include paths are in use. gcc prints:

    #include "..." search starts here:
    #include <...> search starts here:
  2. Try adding -L <path> to the link stage where <path> contains the libraries like lib*.a / lib*.so to be linked against. Add -Wl,-v to see which options the compiler driver passes to the GNU linker ld.

  3. Make sure the symbols are in the libraries, e.g. using tools like nm or x86_64-w64-mingw32-nm.

  4. Make sure you are using libraries cross-compiled using the x86_64-w64-mingw32 toolchain.



Related Topics



Leave a reply



Submit