ld-uClibc.so.0 can be run and provides the expected diagnostics ("chances are you did not intend to run me") Running programs using the hardcoded implicit dynamic loader works too. Running "ld-uClibc.so.0 <binary>" segfaults quite early, before accessing any other files than the <binary>. uClibc is from git around 2011-09-15, it reports itself as 0.9.33-git. The tests were done with FreeBSD 8.1 (Debian kFreeBSD) and 9.0-RC2 (FreeBSD), with the same result. The library is configured and compiled for Linux 2.4.19. No problems detected running on various Linux kernels (2.6.x). Strace output on Linux (ktrace from FreeBSD done and compared but not preserved) Comparing strace on Linux and ktrace on FreeBSD (omitted) output while trying to run "ar" from gnu binutils, compiled and linked with uClibc: ----------------------------------------------------------------------------- execve("/.../ld-uClibc.so.0", ["/.../ld-uClibc.so.0", "/.../ar"], ....... mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb7f7c000 open("/.../ar", O_RDONLY) = 3 fstat(3, {st_dev=makedev(3, 1), st_ino=613642, st_mode=S_IFREG|0555, st_nlink=1, st_uid=2001, st_gid=2001, st_blksize=4096, st_blocks=936, st_size=471140, st_at ime=2011/11/21-16:33:34, st_mtime=2011/11/19-21:47:37, st_ctime=2011/11/19-21:47 :38}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb7f7b000 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0p\226\4\0104\0\0\0\314,\ 7\0\0\0\0\0004\0 \0\7\0(\0\27\0\26\0\6\0\0\0004\0\0\0004\200\4\0104\200\4\10\340 \0\0\0\340\0\0\0\5\0\0\0\4\0\0\0\3\0\0\0\24\1\0\0\24\201\4\10\24\201\4\10\37\0\0 \0\37\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\200\4\10\0\200\4\10T\27\7\0T\27\7\ 0\5\0\0\0\0\20\0\0\1\0\0\0\0 \7\0\0\240\v\10\0\240\v\10P\6\0\0\334I\0\0\6\0\0\0" .., 4096) = 4096 mmap2(0x8048000, 487424, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x804800 0 mmap2(0x8048000, 464724, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8 048000 mmap2(0x80ba000, 1616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x72) = 0 x80ba000 mmap2(0x80bb000, 14812, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOU S, -1, 0) = 0x80bb000 =====> Segfault under FreeBSD happens here, before/instead of close() <====== close(3) = 0 ... ----------------------------------------------------------------------------- How-To-Repeat: Compile uClibc on Linux with support for dynamic linking and explicit runtime loader. Run uClibc runtime loader with a binary (dynamically linked with uClibc) as the argument.
Hello, To make it clear that this is purely a FreeBSD issue: The same test on NetBSD xdat05.ce.chalmers.se 5.1.1 NetBSD 5.1.1 (GENERIC) #0: Wed Jan 4 23:11:44 UTC 2012 builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-1-RELEASE/i386/201201040549Z-obj/home/builds/ab/netbsd-5-1-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386 works fine. Regards, Rune
Assign to maintainer.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
(In reply to Eitan Adler from comment #3) Is this really an issue anymore?