Date: Thu, 24 Sep 1998 13:32:33 -0700 From: Jake Hamby <jake.hamby@jpl.nasa.gov> To: hackers@FreeBSD.ORG Subject: How can I run glibc Linux binaries (RedHat 5.x) on FreeBSD (CURRENT)? Message-ID: <360AAC61.4FE0E3A0@jpl.nasa.gov>
next in thread | raw e-mail | index | archive | help
I just received my beta copy of Oracle8 for Linux, and was curious to
try it out on our FreeBSD-current box (from about a week after the ELF
transition). After branding all of the ELF binaries, I discovered that
they required the new libc.so.6, libm.so.6, and ld-linux.so.2 libraries
from GNU libc 2.0. I FTP'ed them over from my RedHat 5.1 desktop, only
to discover that they immediately dump core. This problem is not unique
to Oracle, as /bin/ls from RedHat also crashes. Here's the ktrace:
19120 ktrace RET ktrace 0
19120 ktrace CALL execve(0xefbfdacb,0xefbfd9b0,0xefbfd9b8)
19120 ktrace NAMI "./ls"
19120 ktrace NAMI "/compat/linux/lib/ld-linux.so.1"
19120 ls RET execve 0
19120 ls CALL dup2(0xefbfd84c)
19120 ls RET dup2 671412224/0x2804f000
19120 ls CALL old.recvfrom(0x8048000,0x6d28,0x7)
19120 ls RET old.recvfrom 0
19120 ls CALL listen(0x40004683,0xefbfd818)
19120 ls NAMI "/compat/linux/etc/ld.so.cache"
19120 ls NAMI "/compat/linux"
19120 ls NAMI "/compat/linux/etc/ld.so.cache"
19120 ls RET listen 0
19120 ls CALL open(0x40004683,0,0)
19120 ls NAMI "/compat/linux/etc/ld.so.cache"
19120 ls NAMI "/compat/linux"
19120 ls NAMI "/compat/linux/etc/ld.so.cache"
19120 ls RET open 3
19120 ls CALL dup2(0xefbfd7e4)
19120 ls RET dup2 671416320/0x28050000
19120 ls CALL close(0x3)
19120 ls RET close 0
19120 ls CALL open(0x2805134f,0,0)
19120 ls NAMI "/compat/linux/lib/libc.so.6"
19120 ls NAMI "/compat/linux"
19120 ls NAMI "/compat/linux/lib/libc.so.6"
19120 ls RET open 3
19120 ls CALL read(0x3,0xefbfc41c,0x1000)
19120 ls GIO fd 3 read 4096 bytes
"\^?ELF\^A\^A\^A\0\0\0\0\0\0\0\0\0\^ ...
19120 ls RET read 4096/0x1000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 671424512/0x28052000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 671424512/0x28052000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 672018432/0x280e3000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 672047104/0x280ea000
19120 ls CALL close(0x3)
19120 ls RET close 0
19120 ls CALL old.recvfrom(0x28052000,0x9079d,0x7)
19120 ls RET old.recvfrom 0
19120 ls CALL open(0xefbfd458,0,0)
19120 ls NAMI "/compat/linux/usr/lib/ld-linux.so.2"
19120 ls NAMI "/usr/lib/ld-linux.so.2"
19120 ls RET open JUSTRETURN
19120 ls CALL open(0xefbfd458,0,0)
19120 ls NAMI "/compat/linux/lib/ld-linux.so.2"
19120 ls NAMI "/compat/linux"
19120 ls NAMI "/compat/linux/lib/ld-linux.so.2"
19120 ls RET open 3
19120 ls CALL read(0x3,0xefbfc41c,0x1000)
19120 ls GIO fd 3 read 4096 bytes
"\^?ELF\^A\^A\^A\0\0\0\0\0\0\0 ...
19120 ls RET read 4096/0x1000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 672096256/0x280f6000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 672096256/0x280f6000
19120 ls CALL dup2(0xefbfc320)
19120 ls RET dup2 672133120/0x280ff000
19120 ls CALL close(0x3)
19120 ls RET close 0
19120 ls CALL old.recvfrom(0x280f6000,0x8fa4,0x7)
19120 ls RET old.recvfrom 0
19120 ls CALL #91(0x28050000,0x1821)
19120 ls RET #91 0
19120 ls CALL old.recvfrom(0x8048000,0x6d28,0x5)
19120 ls RET old.recvfrom 0
19120 ls CALL old.recvfrom(0x28052000,0x9079d,0x5)
19120 ls RET old.recvfrom 0
19120 ls CALL old.recvfrom(0x280f6000,0x8fa4,0x5)
19120 ls RET old.recvfrom 0
19120 ls CALL getpid
19120 ls RET getpid 19120/0x4ab0
19120 ls PSIG SIGSEGV SIG_DFL
19120 ls NAMI "ls.core"
I'd like to help fix this problem myself, but I don't know where to
begin. I'm assuming that kdump prints the FreeBSD, instead of the Linux
syscalls, so I looked them up and old.recvfrom => mprotect(), while dup2
=> mmap() and #91 => munmap(). Looking at a ktrace from
/compat/linux/bin/sh, it appears that this is a fairly normal part of
startup, and looks like the shared libraries mapping in.
The only really unusual thing my untrained eye can see is that both
/compat/linux/lib/ld-linux.so.1 and /compat/linux/lib/ld-linux.so.2 are
being loaded in. But I don't have any idea what to do about it. If I
try copying the newer ld-linux.so.2 as ld-linux.so.1, then FreeBSD
simply complains that it can't find ld-linux.so.1.
Any ideas?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?360AAC61.4FE0E3A0>