From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5321 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ELF loader rejects older glibc binary Date: Thu, 26 Jun 2014 07:44:34 -0400 Message-ID: <20140626114434.GJ179@brightrain.aerifal.cx> References: <20140626035924.GA2714@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403783103 3510 80.91.229.3 (26 Jun 2014 11:45:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Jun 2014 11:45:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5326-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 26 13:44:58 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X086i-0008ND-I7 for gllmg-musl@plane.gmane.org; Thu, 26 Jun 2014 13:44:48 +0200 Original-Received: (qmail 26282 invoked by uid 550); 26 Jun 2014 11:44:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26274 invoked from network); 26 Jun 2014 11:44:46 -0000 Content-Disposition: inline In-Reply-To: <20140626035924.GA2714@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5321 Archived-At: On Wed, Jun 25, 2014 at 08:59:24PM -0700, Isaac Dunham wrote: > Short version: I tried using a "libc6" shared binary that apparently > is compatible with glibc back to 2.1, and musl rejected it as not a valid > dynamic program. > I've used this same binary on Debian 6, so it works elsewhere; but > musl's loader is rejecting it. > > Long version: > I'm trying to use a Brother DCP7065DN network printer with Alpine Linux; > the drivers > are closed-source though modified binaries are redistributable. > The format used is a binary format having some relationship to PCL; > I can't reverse-engineer it, so I'm stuck using the binary drivers > for now. > The drivers in question may be found here: > http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128 > > I grabbed the "LPR printer driver". > After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz), > I found the binaries in > usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/; > the one I'd suggest poking at first is > "usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously determined > that rawtobr3 does all the conversions). > After locating the binaries and verifying with file that they were > dynamically linked ELF binaries, I ran ldd. > When this failed with the message: > ldd: rawtobr3: Not a valid dynamic program > I then ran "strace ldd rawtobr3"; the output indicates that musl mmap'd it > and failed without trying to run it: This error means that map_library either failed to map the program according to its program headers, or found something invalid in the ELF or program headers that it didn't know how to process. > ---start strace output--- > execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0 > open("rawtobr3", O_RDONLY|O_LARGEFILE) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"..., 936) = 936 > mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x566f1000 > munmap(0x566f1000, 49152) = 0 > writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}], 2ldd: rawtobr3: Not a valid dynamic program As you can see, mmap was requested to map at address 0x8048000 but instead chose 0x566f1000. I don't see why this would happen since, at this point, ld-musl and maybe vdso should be the only mappings and the kernel does not put them at such low addresses. > ) = 43 > exit_group(1) = ? > +++ exited with 1 +++ > ---end strace output--- > > strings suggests that it expects glibc 2.1 ABI, and that almost all the > symbol requirements are met (_IO_stdin_used being the possible exception). AFAIK the glibc 2.1 ABI does not have large files, so any function that takes off_t is going to have ABI mismatch, I think. It should be possible to work around this with an LD_PRELOAD library. Eventually I hope to have an internal solution. But this has nothing to do with the load failure so first you need to figure that out. Rich