Does the linker contain .so files on top of .a files?
I am building Julia using a local build of LLVM which contains the libLLVM * .so files and the corresponding libLLVM * .a files. It was first created with BUILD_SHARED_LIBS=ON
which is responsible for the presence of libLLVM * .so files.
libjulia.so, library used by the executable file julia
, is always associated with libLLVM * .so files , even when I rebuilt using LLVM BUILD_SHARED_LIBS=OFF
(the default setting). llvm-config --libs $LIB
the output with and without was BUILD_SHARED_LIBS=ON
not much different, and there is nothing to suggest that it llvm-config
produces link options that bind the linker to any * .so files or * .a files.
Why is this so? Is it the default behavior of the linker to use .so files even when .a files of the same name exist? Or is there a config config cache that Julia reuses?
source to share
Yes to the option -lfoo
, ld
is the default reference libfoo.so
to the preference libfoo.a
, if both are in the same directory search, and when he finds one of them will no longer appear.
You can enforce linking of static libraries only by passing -static
in a link, but in this case static versions should be found for all libraries, including the system default libraries - not just the ones you explicitly mention.
To selectively link a static library libfoo.a
without specifying -static
, you can use the explicit parameter form -l
: -l:libfoo.a
rather than
-lfoo
.
llvm-config
will emit library parameters on a form -lfoo
, whether you create static or shared libraries, as these parameters will work correctly for either, but you have to understand when you use them how the linker behaves. Unless you say otherwise, it will link than the static library when faced with a choice.
Further
Why does ld prefer to link shared libraries over static?
AFAIK, this does not mean that the developers ld
made this decision a long time ago, but the reason is obvious: if dynamic linking is the default, then executables by default will not physically include additional copies of the code that can be provided to all executables by one shared copy from the shared libraries. thus executables, by default, save the size of their code and the collection of excecutables that make up your system or mine will be significantly smaller than it should be without sharing. Shared libraries and dynamic linking were invented so that systems don't bloat with duplicate code.
Dynamic linking brings with it the complication that an executable linked to shared libraries, when distributed to a system other than the one on which it was built, does not carry its dynamic dependencies with it. It is for this reason that all approved mechanisms for installing new binaries on systems - package managers - make sure that all their dynamic dependencies are also installed.
source to share