A legacy makefile that I'm trying to understand has -Wl,-z,origin,-rpath,'$ORIGIN/../lib'
OK, I see -Wl means the following are linker options; the commas will be replaced with spaces.
The manpage for the GNU ld mysteriously only says:
-z keyword
The recognized keywords are:
:
:
origin
Marks the object may contain $ORIGIN.
Likewise the next option -rpath (relative path?) contains this $ORIGIN suggesting it's some kind of key word but $ORIGIN is not otherwise mentioned in the ld man page.
$ORIGIN is mentioned under Substitution Sequences in the ELF specification. DF_ORIGIN is documented as well.
However, while GNU ld supports setting the DF_ORIGIN flag with the -z origin option, the dynamic loader in glibc always honors $ORIGIN, even if the flag is not set. This means that there is no reason to use the link editor flag when building for GNU/Linux.
Related
As an example the following will set RUNPATH
matthewh#ORAC:~/dev/test$ g++ test.cpp -ldl -Wl,-rpath,\$ORIGIN
matthewh#ORAC:~/dev/test$ objdump -x a.out | grep RUN
RUNPATH $ORIGIN
However, as a more complex example I'm trying to set this for a library that is compiled with a makefile generated with configure.
I run
export LDFLAGS=-Wl,-rpath,\$ORIGIN
./configure
make
objdump -x library.so | grep RUN
RUNPATH RIGIN
Obviously Make is expanding $O instead of putting a literal $O in the output.
How do I overcome this? I've tried escaping it but it's presenting strange output into runpath.
Ok, Specifically I'm attempting to compile ilmbase-2.2.1 from OpenEXR and set the RUNPATH. It's more complicated than a single Makefile as it's using recursive Make!
The top level Makefile ends up setting the variable LDFLAGS=
I've tried manually editing that to be $$ORIGIN as suggested in other places but still, it comes through as -Wl,-rpath,RIGIN
Now I'm a bit stuck. Short of editing it after the path is set by rewriting it with some kind of ELF editor which is ugly.
Oh wow. This seems to work.
./configure LDFLAGS='-Wl,-rpath,\$$ORIGIN'
The magic \$$ vs just $$
What's the backslash mean in gnu make then?
Linux separates the linker-time search path and run-time search path.
For the run-time search path, I found the rule for ld.so in its man page (8 ld.so):
DT_RPATH
environment LD_LIBRARY_PATH
DT_RUNPATH
ld.so.cache
/lib, /usr/lib
But for linker-time search path, no luck for ld :(
Man page for ld (1 ld) says, besides -L option:
The default set of paths searched (without being specified with -L) depends on which emulation mode ld is using, and in some cases also on how it was configured.
The paths can also be specified in a link script with the "SEARCH_DIR" command. Directories specified this way are searched at the point in which the linker script appears in the command line.
Does the "default set of paths" depending on emulation mode mean "SEARCH_DIR"?
misssprite, to look for the linker search path for specific ELF emulation just run ld -m<emulation> --verbose | grep SEARCH_DIR
Speaking about the ld itself, the library path search order is the following:
Directories specified via -L command line flags
Directories in the LIBRARY_PATH environment variable
SEARCH_DIR variables in the linker script.
You can look what directories are specified in the default linker script by running ld --verbose | grep SEARCH_DIR. Note that = in the SEARCH_DIR values will be replaced by the value of --sysroot option if you specify it.
Usually ld is not invoked directly, but via compiler driver which passes several -L options to the linker. In the case of gcc or clang you can print the additional library search directories added by a compiler by invoking it with -print-search-dirs option. Also note that if you specify some machine-specific compiler flags (like e.g -m32 as misssprite mentioned) than the linker may use different linker script according to the chosen ELF emulation. In the case of gcc you can use -dumpspecs option to look how different compiler flags affect the linker invocation. But IMHO the simplest way to look for the linker command line is to compile and link a simple program with -v specified.
misssprite, there is no search for ld.so or ld-linux.so in the binutils's ld linker.
When dynamic program is build with gcc, it uses option -dynamic-linker of ld (collect2) program: http://man7.org/linux/man-pages/man1/ld.1.html
-Ifile, --dynamic-linker=file
Set the name of the dynamic linker. This is only meaningful when
generating dynamically linked ELF executables. The default
dynamic linker is normally correct; don't use this unless you
know what you are doing.")
Usually used as runtime loader for ELF, the "ld-linux.so" is registered as interpreter in the dynamic ELF file, program header INTERP (.interp), check output readelf -l ./dynamic_application. This field is for full path, as I understand.
When there is no gcc (directly called 'ld' program) or no this option was given, ld uses hardcoded string of full path to ld.so; and this default is incorrect for most OS, including Linux:
https://github.com/bneumeier/binutils/blob/db980de65ca9f296aae8db4d13ee884f0c18ac8a/bfd/elf64-x86-64.c#L510
/* The name of the dynamic interpreter. This is put in the .interp
section. */
#define ELF64_DYNAMIC_INTERPRETER "/lib/ld64.so.1"
#define ELF32_DYNAMIC_INTERPRETER "/lib/ldx32.so.1"
https://github.com/bneumeier/binutils/blob/db980de65ca9f296aae8db4d13ee884f0c18ac8a/gold/x86_64.cc#L816
template<>
const Target::Target_info Target_x86_64<64>::x86_64_info =
...
"/lib/ld64.so.1", // program interpreter
const Target::Target_info Target_x86_64<32>::x86_64_info =
...
"/libx32/ldx32.so.1", // program interpreter
Correct dynamic linker/loader path is hardcoded in machine spec files of gcc, grep output of gcc -dumpspecs command for ld-linux for -dynamic-linker option value.
I'am reading this Tuto, and I'am trying to link the application using this command: ld test.o –o test.bin, the linker doesn't recognize the -o option :
ld: cannot find –o: No such file or directory
Using ld -help the option -o exist but i don't understand why I'am getting this problem.
This is the linker version.
$ ld -version
GNU ld (GNU Binutils for Ubuntu) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
My good eyes and my bitter experience tell me that you must have copied/pasted some text coming from MS-Office where the dash (-) has been converted to another dash which is unicode or whatever. Notice the length of the dash character in your text.
Actually, the tuto you were refering to is the one at fault, ex in this line:
ld –Ttext 0x7c00 --oformat=binary test.o –o test.bin
Note the 2 infamous "long-dashes" that cannot work on a command line.
Your command as-is, followed by the retyped command. notice something?
ld test.o –o test.bin # long dash, fails
ld test.o -o test.bin # good one, short dash
Since the dash is not the correct one, ld assumes that this is an object file and tries to open it, hence the error.
I have read the ld manual, the -m emulation option refers to emulate the emulation linker, what's the meaning of the description. And the -T scriptfile option can use scriptfile as the linker script, but what the option -Ttext 0 refers to, is it valid?
-Ttext 0 tells the linker to start the program at address 0
15.3 Linker emulation selection
A linker emulation is a "personality" of the linker, which gives the linker default values for the other aspects of the target system. In particular, it consists of
the linker script
the target
several "hook" functions that are run at certain stages of the linking process to do special things that some targets require
http://ftp.gnu.org/old-gnu/Manuals/binutils/html_node/binutils_20.html
I have a .m4 file that appends some flags to the linker, one of which sets the rpath flag. This script was originally written for a GNU version of ld that uses -rpath=<value>, however, I'm trying to run the script on OSX, where the version of ld uses -rpath <value>. The end result is that I see this in my config.log:
ld: unknown option: -rpath=path/to/stuff
Is there a way to detect something about how ld expects flags to be passed in from within my .m4 file so I can output the right format depending on the version available?
You could try to detect if linking succeeds with given flag using AC_LINK_IFELSE macro in your script, for example:
AC_MSG_CHECKING([for rpath flag style])
saved_cflags="$CFLAGS"
CFLAGS="$CFLAGS -Wl,-rpath=."
AC_LINK_IFELSE([AC_LANG_SOURCE([int main(){ return 0;}])],
[RPATH_FLAG=gnu],
[RPATH_FLAG=none])
CFLAGS="$saved_cflags"
if test "x$RPATH_FLAG" = "xnone"; then
CFLAGS="$CFLAGS -Wl,-rpath,."
AC_LINK_IFELSE([AC_LANG_SOURCE([int main(){ return 0;}])],
[RPATH_FLAG=llvm],
[RPATH_FLAG=none])
CFLAGS="$saved_cflags"
fi
AC_MSG_RESULT([$RPATH_FLAG])
And set proper flag based on this detection.