for the static executable, where we don't need PT_DYNAMIC segment, but
still the final executable has the program segments like
Elf file type is EXEC (Executable file)
Entry point 0x2000037f1
There are 8 program headers, starting at offset 64
Type Offset VirtAddr PhysAddr FileSiz
MemSiz Flg Align
PHDR 0x000040 0x0000000200000040 0x0000000200000040 0x0001c0
0x0001c0 R 0x8
INTERP 0x000200 0x0000000200000200 0x0000000200000200 0x00000f
0x00000f R 0x1
[Requesting program interpreter: /lib/ld64.so.1]
LOAD 0x000000 0x0000000200000000 0x0000000200000000 0x011100
0x011100 R E 0x1000
LOAD 0x011fd0 0x0000000200013fd0 0x0000000200013fd0 0x000330
0x000898 RW 0x1000
TLS 0x000000 0x0000000000000000 0x0000000000000000 0x000000
DYNAMIC 0x000000 0x0000000000000000 0x0000000000000000 0x000000
readelf: Warning: the .dynamic section is not contained within the dynamic
NOTE 0x000000 0x0000000000000000 0x0000000000000000 0x000000
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW 0x8
Version used :
GNU ld (GNU Binutils) 2.33.1
Copyright (C) 2019 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
This program has absolutely no warranty.
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter *empty*, not stripped
the same script used both static and dynamic executables, one solution
would be like have two scripts with PT_DYNAMIC and without.
But any inputs or suggestions, how we can use the unified script for both
static and dynamic executables?
Re: Differentiate b/w dynamic and static executables.
On 26.12.19 14:46, Umesh Kalappa wrote:
> for the static executable, where we don't need PT_DYNAMIC segment, but
> still the final executable has the program segments like
The static executable also doesn't need a PT_INTERP segment, in fact it
shouldn't have one.
It might in theory be possible to build a unified linker script, but I'd
expect separate scripts to be more maintainable. If you do something
interesting in a script like collect fragments into lists (like C++
global initializers) then it is usually better to make a preliminary
link with a linker script that resolves the common parts and generates
another relocatable output, and then a final link that maps the sections
Note that the standard C and C++ libraries are very much dependent on
their startup code, and that startup code defines a set of sections that
need to be linked in a particular way to work, so at the very least your
scripts also need to know about the requirements of the C/C++ libraries
The linker scripts shipped with the compiler are generated with a
preprocessor from a common source, but separate scripts are generated
for different cases (static/dynamic/shared/... debug/nodebug ...), so it
is likely not possible in a sensible way.