But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it ...
The usual dynamic linker on Linux uses a cache to find its libraries. The cache is stored in /etc/ld.so.cache, and is updated by ldconfig which looks on the paths it’s given in /etc/ld.so.conf (and nowadays typically files in /etc/ld.so.conf.d).
So there is no default value for LD_LIBRARY_PATH, default library lookup doesn’t need it at all. If ...
Yes, it is normal that you don't have any explicit LD_LIBRARY_PATH. Read also ldconfig(8) and ld-linux(8) and about the rpath. Notice that ldconfig updates /etc/ld.so.cache, not the LD_LIBRARY_PATH. Sometimes you'll set the rpath of an executable explicitly with -Wl,-rpath,directory passed to gcc at link time.
If you need a LD_LIBRARY_PATH (but you probably ...
ldconfig can list all the libraries it has access to. These libraries are also stored in its cache.
/sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you're a non-root user). It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what ...
You probably don’t want to “solve” this problem; according to the Debian glibc manpage for ld.so,
/etc/ld.so.nohwcap When this file is present the dynamic linker will load the non-optimized version of a library, even if the CPU supports the optimized version.
It’s not installed by a package, it can be created by the system administrator to ...
LD_LIBRARY_PATH is suitable for short tests, but since there is only one variable, it is awkward to use when you might have multiple applications with custom libraries.
The usual way for Debian/Ubuntu is to add it to the loader's configuration, e.g., a file under
containing the directory in which you want the loader to search, e.g.,
if your libraries are not on standard path then either you need to add them to the path or add non-standard path to LD_LIBRARY_PATH
Once you done any one of above things then you need to update the dynamic linker run-time binding by executing below command:
If we (for the moment) ignore the gcc or linking portion of the question and instead modify a binary with patchelf on a linux system
$ ldd hello
linux-vdso.so.1 => (0x00007ffd35584000)
libhello.so.1 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007f02e4f6f000)
Without getting too technical: Both are "linkers", i.e. a tool that combines/loads a piece of compiled code with/into another piece of compiled code.
ld is a static linker, while ld.so is a dynamic linker.
The letters so are, I believe, short for "shared object", and you'll usually see it as a file name suffix of shared libraries, i.e. libraries that may ...
The entries in /etc/ld.so.conf are searched in order. Therefore, order matters.
This only matters if the same library name (precisely speaking, the same SONAME) is present in multiple directories. If there are directories that you are absolutely sure will never contain the same library then you can put them in the order you prefer.
In particular this means ...
In recent versions of Linux, you can unshare the mount namespace. That is, you can start processes that view the virtual file system differently (with file systems mounted differently).
That can also be done with chroot, but unshare is more adapted to your case.
Like chroot, you need superuser priviledged to unshare the mount namespace.
So, say you have ~/...
The “emulation” selects different linker scripts; you’ll find the scripts themselves in /usr/lib/ldscripts on your system. The emulations you’ve listed correspond to
elf32_x86_64: ELF for x64-32, aka x32 — 32-bit x86-64 binaries
elf_i386: ELF for i386 — 32-bit i386 binaries
i386linux: a.out for i386
i386pep: PE+ for x86-64 — Windows-format 64-bit binaries
LD_LIBRARY_PATH and files in /etc/ld.so.conf.d configure the runtime linker, not the linker used during builds.
To build Julia with MKL, you should
USE_INTEL_MKL = 1
source /opt/intel/bin/compilervars.sh intel64
and build Julia from the same shell (so that the variables set by compilervars are taken into account).
The question is how to determine what linker flag to use from inspection of the source file. The example below will work for Debian. The header files are the relevant items to note here.
So, suppose one has a C source file containing the header
We can do a search for XInput.h using, say apt-file. If you know this ...
It depends on the kernel, and on some kernels it might depend on the type of executable, but I think all modern systems return ETXTBSY (”text file busy“) if you try to open a running executable for writing or to execute a file that's open for writing. Documentation suggests that it's always been the case on BSD, but it wasn't the case on early Solaris (later ...
They are dependencies because the binary lists them as dependencies, as “NEEDED” entries in its dynamic section:
readelf -d /usr/bin/gcc
will show you the libraries gcc requests.
They are unused because gcc doesn’t actually need any of the symbols exported by the libraries in question. In ld-linux-x86-64.so.2’s case, that’s normal, because that’s the ...
The TIS/ELF one covers ELF in general, while the System V ABI is a supplement which documents the x86_64 Application Binary Interface.
The second document does not contain any information about x86_64 since the architecture didn't exist at the time it was written.
This looks as if the binary in question was compiled by you.
So you are responsible for the problem that some libraries cannot be found.
In case that these libraries are available on your system, they seem to be located in non-standard directory locations.
Use -R directory for the final compiler call to tell the linker the directory where the libraries ...
straceing the execve (with environ) and write system calls can help see what's going on:
Here with the stdbuf of GNU coreutils 8.25. I beleive FreeBSD's stdbuf works similarly:
exec and no fork:
$ env -i strace -s200 -vfe execve,write /usr/bin/stdbuf -o0 /usr/bin/env /usr/bin/env > /dev/null
execve("/usr/bin/stdbuf", ["/usr/bin/stdbuf", "-o0", "/usr/...
Create two config files, and point to one of them with a soft link most of the time, but change the soft link to point to the other one when the special app is running.
(I know this is a horrible hack, but it's slightly more reliable than changing file contents).
Or, manipulate $HOME.
In the script which starts the annoying process, set $HOME ...
The best way is probably to create your own rc-script that you will use instead of the "official one".
Otherwise, your rc-script probably includes an external "config" file if you check it. The include may look like this:
So that you can edit /etc/default/mydaemon-config and do something like:
For some reason, probably related to the way the libraries were built (and more specifically, linked), they’ve stored their installation directory in their soname: thus libtatlas.so’s soname is /usr/local/lib/libtatlas.so. ldconfig tries to link libraries to their soname, if it doesn’t exist, in the same directory: it finds /usr/local/lib/libtatlas.so, ...
As far as I know ld ignores LD_LIBRARY_PATH, at least for libraries specified on its command line; LD_LIBRARY_PATH isn’t listed in the environment variables which affect it. It does refer to LD_LIBRARY_PATH when looking for libraries which are needed by other libraries, in native builds, emulating the behaviour of ld.so.
It seems this has something to do with Position Independent Executable (PIE). When GCC compiles executable by defaults it makes them PIE which changes the output flag on the ELF Header to ET_DYN.
You can disable the generation of PIE executables with
If you're seeing this check the default options gcc is configured with gcc -v, you should see ...
Xcode and Fink|Homebrew|MacPorts on Mac OS X have these complications (they just largely hide it from you). There are two aspects to this problem, compiling, and running. Compiling will require a variety of details for any library installed to a custom path. This info for some libraries can be provided by pkg-config, e.g. for a little software depot I ...
Here's a community wiki to collect other distros' equivalent tools for Faheem's method. Feel free to edit, but keep the sort alphabetical for searching.
Use pkgfile from the extra repository, passing the header file name as a parameter.
$ pkgfile XInput.h
(and anything Debian-based using dpkg)
When you add new libraries to the system directories you may need to refresh the linker cache with
This needs to be run as root.
Without this command the runtime linker will have a stale idea of what libraries are available.
You similarly need to do this if you decide to add new directories to the system linker path.
Setting LD_LIBRARY_PATH ...