Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

69

When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you're executing. The loader of a dynamically-linked native executable is the part of the system that's responsible for loading dynamic libraries. It's something like /lib/ld.so or /lib/ld-linux.so.2, and should be an executable file. ...


20

You can temporarily substitute a different library for this particular execution. In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes. The ...


16

The Link Editor Command Language appears to be described in the AT&T UNIX™ PC Model 7300 Unix System V Programmers Guide, chapter 17: The Link Editor. I found a copy of the Programmer's Guide (pdf) at http://www.tenox.net/docs/. The relevant section is on page 524 of the linked .pdf.


16

Write a wrapper script that sets the LD_LIBRARY_PATH environment variable. This is the pendant of PATH for shared libraries. The system search path is always searched after the directories listed in $LD_LIBRARY_PATH. See the dynamic linker manual for reference. #!/bin/sh export LD_LIBRARY_PATH=~/opt/openssl-1.0.1/lib exec /path/to/a.out "$@" Or, for a one-...


14

If fdisk is just an example and your goal is really to make static executables from dynamic executables, try Elf statifier. There's even a comparison with Ermine (by the Ermine vendor, so caveat (non-)emptor). Note that If you have many executables, their combined size is likely to be more than the combined size of the dynamically-linked executables plus ...


10

Installing gcc puts a libstdc++.so.6 into both $PREXIF/lib and $PREFIX/lib64. Using the latter as RPATH for boost and my program solved the issue. Using only the former results in a fall-back to the system libstdc++.so.6.


8

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 ...


7

When you see a file named .so, it’s not necessarily a shared library. These files are used when linking a program at build-time, not run-time; they are commonly symlinks to the real shared library, but at least on systems using GNU ld they can also be linker scripts, and that’s perfectly OK. If you look on a modern glibc-based system you’ll find that libc.so ...


6

The main entry point is God. Be it a C or C++ source file, it is the center of the application. Only in the same way that nitrogen is the center of a pine tree. It is where everything starts, but there's nothing about C or C++ that makes you put the "center" of your application in main(). A great many C and C++ programs are built on an event loop or an I/O ...


6

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 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Your_non-Standard_path> Once you done any one of above things then you need to update the dynamic linker run-time binding by executing below command: sudo ldconfig UPDATE: You ...


5

I have also .1 as I can see from the content it is used for manual Yes, these are written in groff markup. They aren't compiled, they're interpreted at runtime via man or some other viewer (using groff as a backend). The .1 actually denotes the manual section (see man man). When an executable is installed into an element of the system's executable path ...


5

Run ldd(1) on your perl binary. Often the seemingly confusing Not found error on a file that is clearly there is because one of the shared libraries used by the program is not found. So it is possible that your chroot is incomplete with respect to the shared libraries needed by your binaries.


5

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 /etc/ld.so.conf.d containing the directory in which you want the loader to search, e.g., /...


5

It is both, which is perfectly valid. The ld.so-style naming scheme is largely historical; the first dynamic linker in this style was SunOS 4’s, which was named ld.so (I have its history somewhere, I’ll clarify this once I’ve found it). But there are valid reasons for it to be named like a shared library rather than an executable, including: it exists to ...


5

I take it you’re using Jeff Darcy’s definitions: static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time; static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started. It doesn’t really make sense to try ...


4

It will depend on where the file is, in my case it works like this: :~$ locate gcc_s /lib/x86_64-linux-gnu/libgcc_s.so.1 /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so /usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc_s.so And you have to make sure that path is present in one of the ld.so.conf files like: :~$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf # Multiarch ...


4

What matters is what Linux distribution each machine uses, because they handle library paths differently. On the Gentoo (Sabayon) machine, if you want a third party library to be usable system-wide, you should: Create a file under /etc/env.d/ that will contain the additional environment setup. The files are named using the scheme [0-9][0-9]somename - the ...


4

Not at all. One involves redirecting all references to a file name ( any kind of file ) to a different file instead ( symlinks ), and the other involves building an executable image by copying code from a library into the executable ( static linking ) or referencing a dynamic library that contains the required code and loading that dynamic library at ...


4

You would be interested in removing library paths if a given shared library has embedded paths via the rpath feature. Those are added at the time the library is created by the linker. You can remove (or alter) those paths using chrpath, e.g., chrpath -d mylibraryfile.so Removing pathnames from the LD_LIBRARY_PATH variable also is a possible area of ...


4

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 ...


3

The direct (perhaps obvious) answer is that the search path for the libraries you are looking at with ldd does not include the directories where the library's own dependencies are located. Normally, unless a library's dependencies are found in system-wide standard locations, the library should have been built with a run path specified (by using the ...


3

You shouldn't be upgrading your toolchain piecemeal. The parts have to work together. The GNU tools allow so much variation that it is essential that the pieces be set up to work together, especially for a cross-compiler. If you need a newer ld for some reason, you should build up a complete toolchain to support it.


3

AFAIK that header file is more an old-school unix or BSD thing, you can find it in Solaris and {Free,Open,Net}BSD: http://svnweb.freebsd.org/base/head/sys/x86/include/frame.h?revision=247047&view=markup On FreeBSD it's /usr/include/machine/frame.h, there's one for each CPU architecture if you have the kernel source installed, or rummage around that ...


3

Have a look at the CUPS port in cygwin-ports, they provide version 1.4.6 as of January 30th 2011. It patches quite a lot...


3

Like Renan said, this is the result of a 32/64 bit mismatch. On OpenSUSE, try zypper in Mesa-32bit to install the 32 bit version of the library. In general, if you have the 64 bit version, you can use rpm -qf to find the package containing the library: % rpm -qf /usr/lib64/libGLU.so.1 Mesa-7.11-11.4.2.x86_64 On OpenSUSE, the naming convention for 32bit-...


3

Since January 2017, the LLVM apt repository includes lld, as do the the snapshot packages available in Debian (4.0 in unstable, 5.0 in experimental). Presumably the release packages for 4.0 and 5.0 will include ldd. To install the upstream packages on Debian or Ubuntu, follow the instructions for your distribution. (Readers tracking Debian unstable can ...


3

You probably need to install the development-package libkrb5-dev or krb5-multidev: apt-get install libkrb5-dev and need the correct parameters for gcc (run krb5-config.mit gssrpc --libs to get them): gcc test.c -o test $(krb5-config.mit gssrpc --libs) which expands to (depending on the system): gcc test.c -o test -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,...


3

Apple Macos uses clang as it's gcc compiler mainly because of the gcc licensing. You can install GNU gcc using brew. No apple program installs GNU gcc but you can do it manualy and configure to use it by default.


3

It looks like you are trying to link against the openssl libraries installed with your os, rather than the homebrew libraries. Try to find where homebrew installed the 1.0.2k libraries. find /usr/local/Cellar/ -name "libssl.*" You should find something like /usr/local/Cellar/_path_of some_sort/libssl.a. Try to link against this library rather than the ...


3

Your gcc command combines the compile and link phase, so you need to add all the options given: gcc -Iincludepath myFile.c -Llibpath -lcudnn replacing includepath and libpath as appropriate. And yes, you’ll probably want to edit your .bashrc to set LD_LIBRARY_PATH: export LD_LIBRARY_PATH=libpath:$LD_LIBRARY_PATH replacing libpath as appropriate. ...


Only top voted, non community-wiki answers of a minimum length are eligible