Hot answers tagged

27

The gold linker was designed as an ELF-specific linker, with the intention of producing a more maintainable and faster linker than BFD ld (the “traditional” GNU binutils linker). As a side-effect, it is indeed able to link very large programs using less memory than BFD ld, presumably because there are fewer layers of abstraction to deal with, and because 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.


13

The gold linker was written to make the link process considerably faster. According to the gold auther Ian Lance Taylor At the moment gold has only one significant advantage over the existing linker: it is faster. On large C++ programs, I have measured it as running five times faster. He is comparing gold linker performance with the traditional GNU ...


12

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


12

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


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.


10

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


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


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

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


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

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


5

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


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

Since January 2017, the LLVM apt repository includes lld, as do the snapshot packages available in Debian (starting with 4.0 in unstable, 5.0 in experimental). Since version 5, lld packages are available in Debian (lld-5.0 in stretch-backports, lld-6.0 in stretch-backports and Debian 10, lld-7 in Debian 9 and 10, lld-8 in buster-backports, and later packages ...


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

The .data section contains the data itself, i.e. the four bytes which hold the int value 5. The .symtab section contains the symbols, i.e. the names given to various parts of the binary; the var_global_init symbol name points to the four bytes of storage in the .data section. That’s why you only see one entry: there is only one symbol, in the symbol table. ...


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

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

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

As of 2018 lld seems mature enough to be used in production, not 100% compatible with bfd, but can be used as drop-in replacement in most cases.


3

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


3

It turns out I used the wrong zimg. The correct zimg is sekrit-twc/zimg.


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

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


3

This is largely covered by the prelink manpage: prelink is a program that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases. Due to fewer relocations, the run-time memory consumption ...


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