ldd.host bug (32 vs. 64 bit)

Sedat Dilek sedat.dilek at gmail.com
Wed Jun 4 22:30:02 UTC 2014


On Tue, May 8, 2012 at 9:41 PM, Bernhard Reutner-Fischer
<rep.dot.nop at gmail.com> wrote:
> On Sat, May 05, 2012 at 01:22:29PM +0200, Oliver Metz wrote:
>>Hi all.
>>
>>Almost 2 years passed by when I sent the below mail to this list. Unfortunately no one has responded. But ldd is still broken when cross-compiling for a different architecture (32 vs. 64 bit). As a workaround we use "-m32" in the Freetz Project to build the utils [1]. Unfortunately I don't have the knowledge to fix this. So help is appreciated.
>>
>>Regards
>>Oliver
>>
>>[1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/uclibc.mk#L152
>>
>>--
>>Hi,
>>I'm building a mipsel uclibc (0.9.31) toolchain (32-bit) on 64-bit Ubuntu. When trying to analyze a mipsel binary with ldd.host it fails with: "...not an ELF file."
>>
>>This is caused by the following test in http://git.uclibc.org/uClibc/tree/utils/ldd.c#n220:
>>|| ehdr->e_ident[EI_CLASS] != ELFCLASSM
>>
>>The first expression evaluates to ELFCLASS32 and the second one is defined as ELFCLASS64. Commenting out the check doesn't help because then it's throwing a segfault.
>>
>>Can anybody confirm this bug? Or even fix it? Should I open a ticket on bugzilla?
>
> I confirm this behaviour. You can stick the targets wordsize into
> BUILD_CFLAGS=-m32 or keep it passing in via HOSTCC, of course.
>
> I did not look to see if we could tweak byteswapping (or to work for the
> case where the host is able to run binaries of a lower wordsize via
> STANDALONE support).

On this topic I fell over this patch while looking through some uClibc patches.
Have a look at it, Bernhard.

- Sedat -

[1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.32.1/100-fix_hosttools.patch


More information about the uClibc mailing list