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>