I am trying to link some files. Here is my command: gcc -T linker.ld -o Stack\ Berry.bin -ffreestanding -O2 -nostlib kernel.o boot.o -fPIC -lgcc How ever, I get this error: /usr/bin/ld: boot.o: relocation R_X86_64_32 against `.multiboot' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output I have included the -fPIC argument, have I just put it in the wrong place? I haven't been able to find any thing for the syntax for this flag. Thanks!

I am running cmake and it is passing a flag to my linker that is unrecognized (-rdynamic), and it's causing an error. I cannot figure out where it is getting this flag from, so I want to just filter it out. I can specify -DCMAKE_LINKER=, so what I would like to do is set `` to a program that reads its command line arguments, filters out the bad one, and then passes the result back to the actual linker. I have been using awk '{gsub("-rdynamic", "");print}', but I don't know to make the input stdin and the output ld.

Paths to ELF shared objects in LD_PRELOAD cannot contain spaces, as space is one of the two list separators, and it cannot be escaped: > LD_PRELOAD > > A list of additional, user-specified, ELF shared objects to be loaded before all others. This feature can be used to selectively override functions in other shared objects. > > The items of the list can be separated by spaces or colons, and there is no support for escaping either separator. Source: https://manpages.debian.org/bookworm/manpages/ld.so.8.en.html So assuming I want to execute program myprogram and preload an ELF shared object from /path/with space/lib/libsomething.so, then this doesn't work: $ LD_PRELOAD="/path/with space/lib/libsomething.so" myprogram ERROR: ld.so: object '/path/with' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'space/lib/libsomething.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ...

I'm trying to compile VTK from source and I received the following error. I'm running Fedora 27, kernel version 4.14.11-300.fc27.x86_64 /usr/lib64/libSM.so: undefined reference to `uuid_generate@UUID_1.0' /usr/lib64/libSM.so: undefined reference to `uuid_unparse_lower@UUID_1.0' ldd /usr/lib64/libSM.so shows $ldd /usr/lib64/libSM.so linux-vdso.so.1 (0x00007ffd4998b000) libICE.so.6 => /lib64/libICE.so.6 (0x00007f3aa36ff000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f3aa34fa000) libc.so.6 => /lib64/libc.so.6 (0x00007f3aa3115000) /lib64/ld-linux-x86-64.so.2 (0x00007f3aa3b23000) Further looking at the symbols in libuuid.so.1 shows $objdump -T /lib64/libuuid.so.1 | grep 'uuid_generate$' 0000000000002370 g DF .text 0000000000000087 UUID_1.0 uuid_generate $objdump -T /lib64/libuuid.so.1 | grep 'uuid_unparse_lower' 0000000000002710 g DF .text 0000000000000002 UUID_1.0 uuid_unparse_lower The output of ldconfig is $sudo ldconfig -p | grep libuuid libuuid.so.1 (libc6,x86-64) => /lib64/libuuid.so.1 libuuid.so.1 (libc6) => /lib/libuuid.so.1 $ sudo ldconfig -p | grep libSM libSM.so.6 (libc6,x86-64) => /lib64/libSM.so.6 libSM.so.6 (libc6) => /lib/libSM.so.6 libSM.so (libc6,x86-64) => /lib64/libSM.so I'm not sure, what is going on here. Can someone please help? Thank you Senthil

I am working on a new CentOS 8 server to replace an aging CentOS 6 server. Most everything is working and I am having the primary users test out everything they use the server for. Many errors have come and gone but this one not so much. The user is running a gcc command: gcc process-hdf.c -o process-hdf.exe -I/usr/include/hdf -L/usr/lib64 -lmfhdf -ldf -ljpeg -lz -lnsl -lm which ends up failing with /usr/bin/ld: cannot find -lnsl I have done the following so far: - Ran ld -l nsl, same error as with gcc. - Verified that libnsl is installed within /usr/lib64. - Verified both packages, libnsl and libnsl2 are installed. - Checked the ldconfig cache and both versions of libnsl are listed. - Removed the libnsl package, other packages depend on libnsl2. No change when removed. Any info would be appreciated.

**Debian 8 Jessie, OpenSSL version 1.1.0, cURL version: 7.50.2** I am trying to build curl on a Linux Debian system. All stages go well up until trying to build with make command. The linking stage fails with the following error below: CC ../lib/curl-nonblock.o CC ../lib/curl-warnless.o CCLD curl ../lib/.libs/libcurl.so: undefined reference to 'RAND_egd' collect2: error: ld returned 1 exit status Makefile:771: recipe for target 'curl' failed make: *** [curl] Error 1 RAND_egd function is part of the OpenSSL library so I ran ldd on the libcurl.so file to make sure the OpenSSL library is found, and it is judging by the output from ldd below. linux-vdso.so.1 (0x00007ffceb5a1000) libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007ff9ffc05000) libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007ff9ff9d1000) libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007ff9ff7a8000) libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007ff9ff53a000) libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007ff9ff0af000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007ff9feea0000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007ff9fec4e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff9fea33000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff9fe688000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007ff9fe3a6000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff9fe1a2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff9fdf85000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff9fdd6e000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007ff9fdb52000) libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x00007ff9fd833000) /lib64/ld-linux-x86-64.so.2 (0x00007ffa0009e000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007ff9fd621000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007ff9fd3db000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007ff9fd1c7000) libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007ff9fcf95000) libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2 (0x00007ff9fcd66000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007ff9fcae3000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff9fc8db000) So the library is there. I also checked the rand.h file in the include directory of OpenSSL and of course the function declaration is there, so it should be defined in the library. How can I find the cause of and resolve this error?

I've read **a lot** of guidance that says the LD_LIBRARY_PATH is searched before anything else, but one of my .so libraries is linking with libtdc++.so.6 in /usr/lib64. ldd mylib.so: ... libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f82abd18000) ... I want mylib.so to link with libstdc++.so.6 in another location, like /apps/gcc_4.8.0/lib/libstdc++.so.6 So I add /apps/gcc_4.8.0/lib to LD_LIBRARY_PATH, which ***does not*** have /usr/lib64 in it, but it still doesn't find it there. If I add: setenv LD_PRELOAD /apps/gcc_4.8.0/lib/libstdc++.so.6 to my environment, there are no more linker errors. Yay, but that doesn't solve the problem. Users downstream aren't going to want to depend on this library being in the proper place. WHY ISN"T LD_LIBRARY_PATH BEING SEARCHED FIRST!?!

On UNIX, I may use a commandline like: cc -o executable *.o -zlazyload -lsomelib with the result that the libraries listed to the right of -zlazyload are marked with the LAZYLOAD ELF tag in the binary. This may be verified by calling dump -Lv executable and the result contains e.g.: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value POSFLAG_1 LAZYLOAD NEEDED libsecdb.so.1 In this case, libsecdb is not loaded at the startup time of the executable, but delayed to the time, when the first function from libsecdb is called. This trick may be used to keep the incore representation of the executable smaller if it does not use all features. Is there a way to achive the same on Linux? The GNU linker seems to have a flag -zlazy, but my experience is that this is without effect. The background for this question is that on Solaris, it is simple to link the current Bourne Shell (bosh) using lazy linking and this results in a shell that is nearly as small as dash when executing shell scripts, but that is still faster than dash. The shared libraries for the interactive history editor are only linked if the shell is used in interactive mode.

Based on https://unix.stackexchange.com/questions/784690/limit-file-io-speed I have built https://git.data.coop/tange/tangetools/src/branch/master/iothrottle It works for some programs: iothrottle -i 10M cat foo > bar # Yes, here you could just use pv iothrottle -o 1M ffmpeg -i foo.mp3 foo.wav iothrottle -o 1M cp -a foodir /other/fs/foodir This does not: iothrottle -o 1M cp -a foodir /same/fs/foodir because on the same file system cp uses a single call to copy_file_range per file. I am OK with that limitation. It also does not work for seq. When I run strace seq 100000 I get: ~~~ write(1, "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 8192) = 8192 write(1, "\n1861\n1862\n1863\n1864\n1865\n1866\n1"..., 4096) = 4096 write(1, "2680\n2681\n2682\n2683\n2684\n2685\n26"..., 4096) = 4096 write(1, "499\n3500\n3501\n3502\n3503\n3504\n350"..., 4096) = 4096 write(1, "18\n4319\n4320\n4321\n4322\n4323\n4324"..., 4096) = 4096 write(1, "7\n5138\n5139\n5140\n5141\n5142\n5143\n"..., 4096) = 4096 write(1, "\n5957\n5958\n5959\n5960\n5961\n5962\n5"..., 4096) = 4096 write(1, "6776\n6777\n6778\n6779\n6780\n6781\n67"..., 4096) = 4096 write(1, "595\n7596\n7597\n7598\n7599\n7600\n760"..., 4096) = 4096 write(1, "14\n8415\n8416\n8417\n8418\n8419\n8420"..., 4096) = 4096 write(1, "3\n9234\n9235\n9236\n9237\n9238\n9239\n"..., 3838) = 3838 ~~~ So it seems to call write (and not some mmap or other magic), and thus ought to work. But when I run: IOTHROTTLE_DEBUG=1 iothrottle -o 1M seq 10000 >/dev/null I get: ~~~ init called: default read_limit=0, write_limit=0 IOTHROTTLE_READ=0 IOTHROTTLE_WRITE=1048576 Final read_limit=0, write_limit=1048576 allowed: 608 written: 0 allowed: 617 written: 0 ~~~ This tells me that iothrottle only intercepts 2 calls to write. What am I missing?

Compiling code with GCC or Clang can result in some colorful error outputs. Linking code, however, doesn't enjoy the same luxury. It seems like the GNU Linker doesn't support colorized error output right out of the box. Is there a way around this? Is it possible to colorize/stylize linker errors from ld?

When we run ldd on some file, there are two possible results: If the file is dynamic executable, the shared dependencies are shown, for example:

# ldd /usr/bin/sleep
        linux-vdso.so.1 (0x00007ffff7fc7000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff7dd6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc9000)

Or, if the file is either a static executable or not an executable at all, we see not a dynamic executable, for example

# ldd /usr/bin/toybox
        not a dynamic executable
# ldd /etc/shadow
warning: you do not have execution permission...
        not a dynamic executable

But I have also discovered a special case! It takes place if you ever happen to invoke ldd on /usr/sbin/ldconfig. Then, ldd will **explicitly** say that the binary is statically linked!

# ldd /usr/sbin/ldconfig
        statically linked

I'm very interested to know why this happens, what's so special about the ldconfig binary? Thanks.

I am trying to run adbd from within a chrooted environment. I can run it fine with Android's LD_LIBRARY_PATH=$PWD ./linker64 $PWD/adbd. When I try to run ./adbd I get: bash: ./adbd: cannot execute: required file not found. Running with strace $PWD/adbd returns:

execve("/root/adbd", ["/root/adbd"], 0x7fcfe8dfd0 /* 8 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

What dynamic linker is missing and on which path?

touch /tmp/debug.log LD_DEBUG=all LD_DEBUG_OUTPUT=/tmp/debug.log ls After doing this I expect debug info to be written to the /tmp/debug.log file, but it is empty. Ubuntu 20.04

/lib # ./ld-musl-x86_64.so.1 --list /usr/lib/libEGL.so.1
        ./ld-musl-x86_64.so.1 (0x7f2b06797000)
        libdl.so.2 => ./ld-musl-x86_64.so.1 (0x7f2b06797000)
        libm.so.6 => ./ld-musl-x86_64.so.1 (0x7f2b06797000)
        libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x7f2b06000000)
        libc.so.6 => ./ld-musl-x86_64.so.1 (0x7f2b06797000)
Error relocating /usr/lib/libGLdispatch.so.0: __strdup: symbol not found
Error relocating /usr/lib/libEGL.so.1: __strdup: symbol not found

I have set /etc/ld-musl-x86_64.path1 to include directory where libc.so.6 is located. I even tried moving libc.so.6 to /lib but it did not help. It still mislinks to ld-musl-x86_64.so.1 instead of the actual libc.so.6. How can I make it use the actual libc.so.6? 1. [https://wiki.musl-libc.org/faq](https://wiki.musl-libc.org/faq#Q:_Where_is_%3Ccode%3Eldconfig%3C/code%3E?)

Author information can be difficult to find for projects whose histories go back long before their git repositories. According to Wikipedia, Richard Stallman wrote [gcc](https://en.wikipedia.org/wiki/GNU_Compiler_Collection) , and Dean Elsner wrote [GNU as](https://en.wikipedia.org/wiki/GNU_Assembler) . Who wrote the GNU linker, ld?

I'm trying to debug my build environment for compiling a linux kernel with some patch sets. I installed devtoolset-9 in my CentOS 7 environment to satisfy the minimum gcc version requirement of the 5.15.86 linux kernel branch. When compiling the kernel with a simple

bzImage

, I get the following error: make: *** No rule to make target scripts/extract-cert', needed by certs/x509_certificate_list'. Stop. I then tried to make extract-cert by cd'ing to scripts and running

extract-cert

, but get the following error: cc extract-cert.c -o extract-cert /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: /tmp/ccx32b6d.o: in function `display_openssl_errors': extract-cert.c:(.text+0x3e): undefined reference to `ERR_peek_error' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x7f): undefined reference to `ERR_error_string' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0xc2): undefined reference to `ERR_get_error_line' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: /tmp/ccx32b6d.o: in function `drain_openssl_errors': extract-cert.c:(.text+0xdd): undefined reference to `ERR_peek_error' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0xf6): undefined reference to `ERR_get_error_line' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: /tmp/ccx32b6d.o: in function `write_cert': extract-cert.c:(.text+0x132): undefined reference to `BIO_new_file' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x186): undefined reference to `X509_get_subject_name' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x1a0): undefined reference to `X509_NAME_oneline' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x1b9): undefined reference to `i2d_X509_bio' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: /tmp/ccx32b6d.o: in function `main': extract-cert.c:(.text+0x230): undefined reference to `OPENSSL_add_all_algorithms_noconf' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x235): undefined reference to `ERR_load_crypto_strings' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x23a): undefined reference to `ERR_clear_error' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x338): undefined reference to `ENGINE_load_builtin_engines' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x347): undefined reference to `ENGINE_by_id' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x386): undefined reference to `ENGINE_init' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x3e2): undefined reference to `ENGINE_ctrl_cmd_string' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x437): undefined reference to `ENGINE_ctrl_cmd' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x48a): undefined reference to `BIO_new_file' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x4df): undefined reference to `PEM_read_bio_X509' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x4fb): undefined reference to `ERR_peek_last_error' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x522): undefined reference to `ERR_clear_error' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: extract-cert.c:(.text+0x57a): undefined reference to `BIO_free' collect2: error: ld returned 1 exit status make: *** [extract-cert] Error 1 I searched in the OpenSSL source code on github and found the symbols that the linker is complaining about. So it seems that it is an OpenSSL error. I have OpenSSL installed, but I'm not sure how it works with devtoolset-9. How do I get the linker within devtoolset-9 to find the OpenSSL library? The pkgconfig files look correct to me, and the libraries exist in /usr/lib64/ $>gcc --version gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 $>yum list installed | grep ssl openssl.x86_64 1:1.0.2k-26.el7_9 @updates openssl-devel.x86_64 1:1.0.2k-26.el7_9 @updates openssl-libs.x86_64 1:1.0.2k-26.el7_9 @updates $>find . -name 'libssl*' ./usr/lib64/pkgconfig/libssl.pc ./usr/lib64/libssl.so.1.0.2k ./usr/lib64/libssl.so.10 ./usr/lib64/libssl3.so ./usr/lib64/libssl.so $>cat ./usr/lib64/pkgconfig/libssl.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib64 includedir=${prefix}/include Name: OpenSSL-libssl Description: Secure Sockets Layer and cryptography libraries Version: 1.0.2k Requires: libcrypto Libs: -L${libdir} -lssl Libs.private: -ldl -lz -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto Cflags: -I${includedir} -I/usr/include $>cat ./usr/lib64/pkgconfig/libcrypto.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib64 includedir=${prefix}/include enginesdir=/usr/lib64/openssl/engines Name: OpenSSL-libcrypto Description: OpenSSL cryptography library Version: 1.0.2k Requires: Libs: -L${libdir} -lcrypto Libs.private: -ldl -lz Cflags: -I${includedir} **@Ginnungagap:** The result of echo | gcc -xc -E -v - is: $> echo | gcc -xc -E -v - Using built-in specs. COLLECT_GCC=gcc Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-9/root/usr --mandir=/opt/rh/devtoolset-9/root/usr/share/man --infodir=/opt/rh/devtoolset-9/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-9.3.1-20200408/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64' /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/cc1 -E -quiet -v - -mtune=generic -march=x86-64 ignoring nonexistent directory "/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/include-fixed" ignoring nonexistent directory "/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include search starts here: /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/include /usr/local/include /opt/rh/devtoolset-9/root/usr/include /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "" 2 # 1 "" COMPILER_PATH=/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/:/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/:/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/:/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/:/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/:/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'

There are at least two standards of [Executable and Linkable Format (ELF)](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) , one of them * [System V Application Binary Interface AMD64 Architecture Processor Supplement (With LP64 and ILP32 Programming Models) Version 1.0](https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf) * [Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2](http://refspecs.linuxbase.org/elf/elf.pdf) The older one, the TIS ELF Standard 1.2 is 106 pages while the SysV ABI is 157 pages but covers ELF only on pages 63-86 (23 pages). How do these two standards relate to each other? And which one does Linux and GNU Linker use? What is the Tool Interface Standard?

i am trying to compile a kernel but it always return this error:

LD      arch/arm64/kernel/vdso/built-in.o
ld.lld: error: cannot find linker script -r
make: *** [scripts/Makefile.build:507: arch/arm64/kernel/vdso/built-in.o] Error 1
make: *** [scripts/Makefile.build:647: arch/arm64/kernel/vdso] Error 2
make: *** [Makefile:1239: arch/arm64/kernel] Error 2

i have examined the sources, scripts and Makefiles from vdso but no luck. can anyone point me how and where to look into this matter, or how to show more details about this please? regards edit: i am trying to build an android kernel with llvm for the first time on my ubuntu 20.04, which i believe i have setup clang17 & gcc probably. but it produced the same error even compiled with gcc here is the config settings:

CLANG_HOME=/usr/lib/llvm-17
export PATH=$CLANG_HOME/bin:$CLANG_HOME/lib:${PATH}
export CLANG_TRIPLE=/usr/bin/aarch64-linux-gnu-
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
export CROSS_COMPILE_ARM32=/opt1/android/toolchain/clang/proton-clang-v13.0.0/arm-linux-gnueabi/bin/arm-linux-gnueabi-
export CC=$CLANG_HOME/bin/clang
export REAL_CC=$CLANG_HOME/bin/clang
export LD=$CLANG_HOME/bin/ld.lld
export AR=$CLANG_HOME/bin/llvm-ar
export NM=$CLANG_HOME/bin/llvm-nm
export OBJCOPY=$CLANG_HOME/bin/llvm-objcopy
export OBJDUMP=$CLANG_HOME/bin/llvm-objdump
export READELF=$CLANG_HOME/bin/llvm-readelf
export STRIP=$CLANG_HOME/bin/llvm-strip
export LLVM=1 && export LLVM_IAS=1
export KALLSYMS_EXTRA_PASS=1
export ARCH=arm64 && export SUBARCH=arm64

errors with make -j1 -V1

make -f ./scripts/Makefile.build obj=arch/arm64/kernel/vdso
  /usr/lib/llvm-17/bin/llvm-objcopy -S  arch/arm64/kernel/vdso/vdso.so.dbg arch/arm64/kernel/vdso/vdso.so
  /usr/lib/llvm-17/bin/clang -Wp,-MD,arch/arm64/kernel/vdso/.vdso.o.d  -nostdinc -isystem /usr/lib/llvm-17/lib/clang/17/include -I./arch/arm64/include -I./arch/arm64/include/generated/uapi -I./arch/arm64/include/generated  -I./include -I./drivers/kernelsu/include -I./arch/arm64/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Qunused-arguments -mlittle-endian -Qunused-arguments -D__ASSEMBLY__ --target=aarch64-linux-gnu -DCC_USE_CLANG --prefix=/usr/bin/aarch64-linux-gnu-
--gcc-toolchain=/usr -Werror=unknown-warning-option -fno-PIE -DCONFIG_AS_LSE=1 -DCONFIG_VDSO32=1   -c -o arch/arm64/kernel/vdso/vdso.o arch/arm64/kernel/vdso/vdso.S
   /usr/lib/llvm-17/bin/ld.lld   -EL  -maarch64elf -O3 -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv --build-id -n -T
-r -o arch/arm64/kernel/vdso/built-in.o arch/arm64/kernel/vdso/vdso.o
ld.lld: error: cannot find linker script -r
make: *** [scripts/Makefile.build:507: arch/arm64/kernel/vdso/built-in.o] Error 1
make: *** [scripts/Makefile.build:647: arch/arm64/kernel/vdso] Error 2
make: *** [Makefile:1239: arch/arm64/kernel] Error 2

edit2: tried with different clang but still having problems when compiling vdso things. most common errors as mentioned above - cannot find linker script, thus built.o was not compiled successfully

Assuming I want to test if a library is installed and usable by a program. I can use ldconfig -p | grep mylib to find out if it's installed on the system. but what if the library is only known via setting LD_LIBRARY_PATH? In that case, the program may be able to find the library, but ldconfig won't. How can I check if the library is in the *combined* linker path? I'll add that I'm looking for a solution that will work even if I don't actually have the program at hand (e.g. the program isn't compiled yet), I just want to know that a certain library exists in ld's paths.

Computer Systems: A Programmer's Perspective (3ed) says on p733 that > **7.9 Loading Executable Object Files** > > To run an executable object file prog, we can type its name to the Linux shell’s command line: > > linux> ./prog > > Since prog does not correspond to a built-in shell command, the shell assumes that prog is an executable object file, which it runs for us by invoking some memory-resident operating system code known as **the loader**. Any Linux program can invoke the loader by calling the execve function, which we will describe in detail in Section 8.4.6 and in p736: during dynamic linking > **7.10 Dynamic Linking with Shared Libraries** > > Once we have created the library, we would then link it into our example program in Figure 7.7: > > linux> gcc -o prog2l main2.c ./libvector.so > > This creates an executable object file prog2l in a form that can be linked with libvector.so at run time. The basic idea is to do some of the linking statically when the executable file is created, and then complete the linking process dynamically when the program is loaded. It is important to realize that **none of the code or data sections from libvector.so are actually copied into the executable prog2l** at this point. Instead, **the linker copies some relocation and symbol table information** that will allow references to code and data in libvector.so to be resolved at load time. > > When the loader loads and runs the executable prog2l, it loads the partially linked executable prog2l, using the techniques discussed in Section 7.9. Next, it notices that prog2l contains a .interp section, which contains the path name of the dynamic linker, which is itself a shared object (e.g., ld-linux.so on Linux systems). Instead of passing control to the application, as it would normally do, the loader loads and runs the dynamic linker. > **The dynamic linker** then finishes **the linking task** by performing the following relocations: > - Relocating the text and data of libc.so into some memory segment > - Relocating the text and data of libvector.so into another memory segment > - Relocating any references in prog2l to symbols defined by libc.so and libvector.so The above dynamic linking case is the "static loading, dynamic linking" case in Stephen Kitt's reply : > static loading, dynamic linking: **the linker** is /usr/bin/ld again, but with shared libraries (.so); **the loader** is the binary’s interpreter, e.g. /lib64/ld-linux-x86-64.so.2 (which maps to /lib/x86_64-linux-gnu/ld-2.24.so currently) on Debian 9 on 64-bit x86, itself loaded by the kernel, which also loads the main executable; The difference is that CSAPP seems to say that the loader is (the kernel code behind) execve() and the linker is ld-linux.so (no linking happens at compile time by ld, and actual linking happens at load time by ld-linux.so). What is the linker and what is the loader in dynamic linking? Thanks.