Cannot Link to Shared Library

Cannot link to shared library

The libraries have to go after the local translation units:

g++ -L. -Wl,-rpath,'.' client.cpp -o client -lrect
#                                           ^^^^^^

It has to do with how unresolved symbols are looked up by the linker; search the internet for a plethora of information on this if you're curious.

Can't link custom shared library with gcc

When linking a library, the library usually has to be named libxxx.a|so for the linker to find it.

Compiling the library:

gcc -I . -fPIC -shared -o libtest.so test_lib.c

Then you can link with:

gcc -I . -L . test.c -ltest

Unable to link .so shared library to main .c file while compiling

I tried to reproduce the problem here, and this error message goes away if you put a space between the -L flag and the tilde character.

The reason is: if there is no space between -L and ~, the tilde character cannot be expanded to the home directory.

Cannot link a shared library for python

-Xlinker -export-dynamic is a single thing which tells GCC to pass -export-dynamic to the linker.

You are misusing python3.6-config --ldflags in the sense that it expects its output to be given to GCC, not to ld directly.

Try this:

gcc \
    $(apr-1-config --link-ld) \
    $(python3.6-config --ldflags) \
    -shared \
    -o mod_demo.so \
    mod_demo.o

Can't link shared library with -mx32 and gcc 4.7 or gcc 4.8

-m32 is normal 32-bit mode, and yes most x86-64 GNU/Linux systems have multiarch support with 32-bit libraries that you can install if not already installed.

The -mx32 option is not what you want at all. It compiles code for the x32 ABI, which uses 32-bit addresses with 64-bit registers and instructions. The resulting code is not compatible with 32-bit processors (as it uses 64-bit instructions), but is also not compatible with 64-bit code (which will use 64-bit addresses). So everything in user-space has to be compiled with it in mind, including libc, and even the kernel needs to support x32 user-space and syscalls: https://unix.stackexchange.com/questions/121424/linux-and-x32-abi-how-to-use (i.e. just like supporting 32-bit binaries, x32 is effectively a separate architecture.)

Complicating matters further, the testing you've been doing on Windows hasn't been doing what you think at all. Passing /DWIN32 to the Visual C++ compiler only defines a macro called WIN32 (like -DWIN32 would for GCC); it doesn't make the compiler generate 32-bit binaries. 64-bit Windows executables cannot load 32-bit libraries; the libraries you've been testing with have actually been 64-bit.

If you want to unit-test 32-bit code, you'll need to test it on a fully 32-bit target architecture like -m32. x32 is not such a system. (32-bit code under a 64-bit kernel is fine, though, unless you're worried about only having 2G or 3GiB of address-space usable by user-space in your embedded system, instead of 4GiB under a 64-bit kernel.)

Can't compile and link with dynamic library

clang hello.c -o hello -Igreeting

attempts to compile and link, but you didn't supply the name of the library to link with:

clang hello.c -o hello -Igreeting greeting.so #<= greeting.so added

Then you should be able to run the output with:

LD_LIBRARY_PATH=. ./hello 

The idea is that the lib will be put in one of your systems library paths and because you haven't done that, the LD_LIBRARY_PATH environment variable is a kind of a hack to make it work without it.

With gcc/clang on Linux, you can also hardcode the full path:

clang hello.c -o hello -Igreeting $PWD/greeting.so

or you can make the dynamic linker search for the dependency relative to the location of the executable

clang hello.c -o hello -Igreeting '-Wl,-rpath=$ORIGIN' greeting.so

With either of the two methods above, you don't need the LD_LIBRARY_PATH=. part anymore.

There's a lot more to dynamic libraries, and I recommend you study up more on them e.g., from Ulrich Drepper's DSO Howto writeup.

Error when trying to link to a shared library I created using LD_PRELOAD

I do not know how to add compiler flag, but you can make it works as follows.

Compile test as usual:

g++ -Wall -g test.cpp -o test -std=c++11 

Invoke it like this:

LD_PRELOAD=/home/nullmalloc/nullmalloc.so ./test

---

Related Topics