ELF loader rejects older glibc binary

[Isaac Dunham <ibid.ag@gmail.com>]

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:

---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
) = 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).


Thanks,
Isaac Dunham