[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Jun 2014 07:44:34 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: ELF loader rejects older glibc binary
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
