Nachträgliches linken von binaries
Florian Lohoff
flo at rfc822.org
Wed Dec 22 14:26:38 CET 1999
On Wed, Dec 22, 1999 at 11:58:17AM +0100, Nils Bokermann wrote:
> > ld -m elf_i386 -static -o test-static -L/usr/lib/gcc-lib/i486-linux/2.7.2.3 test -lgcc -lc -lgcc
> ^^^
[...]
> > (flo at paradigm)/tmp/i# ldd test-static
> > libc.so.6 => /lib/libc.so.6 (0x4000f000)
> ^^^^^^^^^^^^
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > (flo at paradigm)/tmp/i# ./test-static
> > Segmentation fault
>
> Is klar, du hast 2 mal die libc dadrin (und die libgcc auch [aber net
> weiter schlimm, weil die eh static is])
Falsch - Das statische glibc/libgcc dazulinken sollte nur unresolved symbols
aufloesen. Das problem ist ein anderes ..
Zur linkzeit werden die "startfiles" dazugelinkt (crt0.o, __init.o etc). Diese
beinhalten auch die aufrufe fuer den dynamischen linker. Diese "startfiles"
kannst du aber weder entfernen noch ueberschreiben durch "statische" startfiles
Um es zu demonstrieren ....
(root at paradigm)/tmp/i$ gcc -v -o test-static -nostartfiles --static -nostdlib test /usr/lib/libc.a
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
ld -m elf_i386 -static -o test-static -L/usr/lib/gcc-lib/i486-linux/2.7.2.3 test /usr/lib/libc.a
Hier werden weder "libgcc" noch die "startfiles" hinzugelinkt - Trotzdem
funktioniert das ergebnis nicht - Nach einer analyse von objdump -x ein
wenig gespielt ...
(root at paradigm)/tmp/i$ gcc -v -o test-static -nostartfiles --static -nostdlib /usr/lib/libc.a /usr/lib/libpthread.a test
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
ld -m elf_i386 -static -o test-static -L/usr/lib/gcc-lib/i486-linux/2.7.2.3 /usr/lib/libc.a /usr/lib/libpthread.a test
Bleiben noch folgende Symbole unresolved ...
(root at paradigm)/tmp/i$ objdump -x ./test-static | grep UND
00000000 F *UND* 00000007 __libc_init_first
00000000 F *UND* 0000003e atexit
00000000 F *UND* 000000e0 exit
00000000 w *UND* 00000000 __gmon_start__
Jetzt laeuft das minimal binary - Allerdings ist did dependency auf
libc6 und ld-linux.so.2 immer noch vorhanden ...
Wie bekommt man die noch weg ?
Flo
--
Florian Lohoff flo at rfc822.org +49-5241-470566
... The failure can be random; however, when it does occur, it is
catastrophic and is repeatable ... Cisco Field Notice
More information about the Linux
mailing list