From owner-freebsd-current Wed May 22 23:24:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA23649 for current-outgoing; Wed, 22 May 1996 23:24:37 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA23644 for ; Wed, 22 May 1996 23:24:34 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id IAA19007; Thu, 23 May 1996 08:04:33 +0200 Message-Id: <199605230604.IAA19007@ra.dkuug.dk> Subject: Re: Can't run Linux static ELF binaries? To: jehamby@lightside.com (Jake Hamby) Date: Thu, 23 May 1996 08:04:33 +0200 (MET DST) Cc: current@FreeBSD.org In-Reply-To: from "Jake Hamby" at May 22, 96 03:16:58 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jake Hamby who wrote: > What you are seeing is one of the "not so nice" features in ELF. It is currently impossible to tell what OS a static ELF binary is for, so the loader assumes (incorrectly) that it is a native FreeBSD ELF binary and boom.. There is NO pretty fix for this except marking the files in some way. We know the problem and the workaround, but infact we need coorporation with Linux/SVR4/whatever to set a standard for this, so its likely not to happen :( > I just discovered, while trying to upgrade my /compat/linux/lib directory > to the latest version of ld.so (1.7.14), that both the new ldconfig and > ldd coredump immediately when run. Both are statically linked ELF > executables. As a workaround, I installed everything in the ld.so > package except for ldconfig and ldd, and am still using the old a.out > ldconfig and ldd from linux_lib-2.0. > > The only problem is that the old ldconfig doesn't properly recognize > libc.so.5.3.16 and libm.5.0.6 as valid ELF libraries and links the old > versions. Oddly enough, it does link the new version of libc to a file > called "syntax_options". I was able to workaround by deleting the old > libc and libm, and manually creating the proper symlinks to libc.so.5. > > If any of the Linux/ELF-meisters have a chance to look at this bug it > would be a good idea. Personally, I'm busy with adding SVR4 > compatibility from NetBSD, so I might find some bugs from that end, but > don't have time to investigate this one. Thanks! > > ---Jake > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time.