Created attachment 4592 [details] Snippet of build output, showing incorrect linker invocation. I'm using the CodeSourcery mips-4.4 toolchain, and have a little endian target, so I set BR2_TARGET_LDFLAGS="-EL" in my .config. Works fine for most things, however directfb fails to build; at one stage, it invokes the linker, without the -EL argument, and the link fails because the linker (which defaults to BE) is attempting to link LE object files. Dodgy workaround is to replace output/host/usr/bin/mips-linux-gnu-ld with a script that contains: #!/bin/sh exec /opt/CodeSourcery/mips-4.4//bin/mips-linux-gnu-ld -EL $* Relevant build output attached. The interesting parts of my .config are: # # Toolchain # # BR2_TOOLCHAIN_BUILDROOT is not set BR2_TOOLCHAIN_EXTERNAL=y # BR2_TOOLCHAIN_CTNG is not set # BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS201109 is not set # BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS201103 is not set BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS44=y # BR2_TOOLCHAIN_EXTERNAL_CUSTOM is not set # BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD is not set BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y BR2_TOOLCHAIN_EXTERNAL_PATH="/opt/CodeSourcery/mips-4.4/" BR2_TOOLCHAIN_EXTERNAL_PREFIX="mips-linux-gnu" BR2_TOOLCHAIN_EXTERNAL_GLIBC=y BR2_TARGET_OPTIMIZATION="-pipe -EL" BR2_TARGET_LDFLAGS="-EL"
The first problem is that DirectFB is stupid in its usage of ld. It should always use gcc, even for pure linking steps, as gcc will pass the appropriate arguments to ld. The second problem is that we don't generate a toolchain wrapper for ld, so yes the BR2_TARGET_LDFLAGS are not passed. I am not sure if we should fix DirectFB, or add the toolchain wrapper for ld.
Would it help to pass LD="$(TARGET_LD) $(TARGET_LDFLAGS)" to configure?
You mean globally (in package/Makefile.in) or specifically for this package?
Created attachment 4598 [details] Change as suggested by Arnout.
Arnout, I've made the change you suggested to package/directfb/directfb.mk; now directfb, and all the other packages I have selected, are building for me. Patch against 2012.08 attached. I'm not sure how many packages have the same problem as directfb; if there are a few, then I'd imagine that a more robust solution may be to create a toolchain wrapper for ld.
FYI I got similar issue with my LD not having the correct emulation (mips), and I opted to add it to LDFLAGS, "-melf64btsmip" for instance. It fixes packages using LD directly, but a new problem appears: CC cannot recognize such LD specific option syntax, and some packages adds TARGET_LDFLAGS to CC. So I would first clean-up TARGET_LDFLAGS usage before doing the LD wrapper (which sounds good idea).
This problem has been fixed with commit 7e9264956bb5693bc49274ee0b42ffb4c869e23f in buildroot 2013.11.