El 7 d’abril de 2012 23:13, Robert Millan <rmh@debian.org> ha escrit: > See my message in http://sourceware.org/bugzilla/show_bug.cgi?id=12913#c6 This really needs a lot more attention, it's not just a toolchain bug causing FTBFS in gcc. Summary: binutils/gcc/glibc redefined the meaning of ELF osabi field. The new meaning contradicts the one assumed by kernel of FreeBSD. Now on GNU/kFreeBSD it happens that userland thinks osabi field identifies userland, and kernel thinks osabi field identifies kernel. We've lived perfectly well with kernel having the ELFOSABI_FREEBSD (9) requirement for executing binaries, since userland didn't care about ELFOSABI at all. I think to the date GNU/Linux has been using ELFOSABI_NONE (0), rather than ELFOSABI_LINUX (3). Now ELFOSABI_LINUX (3) has been unilaterally redefined. It's now a (deprecated) alias for ELFOSABI_GNU, and it implies GNU userland. Toolchain components begin to use it to check for availability of GNU features. We just found binutils doing this, since binutils is only writing this information it's to be expected that something else [1] (gcc? glibc?) is reading it and requires ELFOSABI_GNU. Unfortunately we can't just switch to ELFOSABI_GNU because the kernel won't identify those binaries as native FreeBSD syscall ABI. I've written a bandaid for binutils. But I'm not sure if that will be enough. I'm worried that runtime errors begin to appear somewhere else, because we don't have the "correct" ELFOSABI. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10549 -- Robert Millan
Attachment:
binutils.diff
Description: Binary data