Hi Ward,

On 02.03.2018 01:02, Ward Willats wrote:
> Greetings from California:
> I am a poor sinner trying to build u-boot from source on Max OSX. Forgive me.
> I have a custom MIPS board with a u-boot from a 3rd-party vendor and we'd 
> like to replace it. The board is MIPS-based and runs OpenWRT/LEDE.
> So...I grabbed the u-boot git repo, stuck it on a case-sensitive filesystem, 
> set up environment variables to allow the OpwenWRT MIPS cross compiler to 
> work, wrote a "hello world" program in the u-boot root directory and cross 
> compiled in on the command line without problem, and then turned my attention 
> to u-boot.
> Thought it would be good to see if I could get something running in QEMU 
> first, so
> Did this:
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- distclean
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- 
> qemu_mipsel_defconfig
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux-
> The first target it tries to build is "tools" using the HOSTCC (x86 LLVM from 
> xcode, masquerading as gcc). It gets as far as AIS Image then poops out 
> because it tries to use the MIPS version of byteorder.h, even though it 
> compiling with HOSTCC:
>   ./arch/mips/include/asm/byteorder.h:70:4: error: "MIPS, but neither 
> __MIPSEB__, nor __MIPSEL__???"
>   #  error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
> Is the system expecting a native/host byteorder.h to be present when using 
> HOSTCC that is to be discovered before the compiler drops into arch/mips? If 
> so, how does that work? Or is this a corner-case bug?

Looks like a corner-case bug with LLVM. I think on a Linux system with HOST GCC 
the header guard "#ifndef _ASM_BYTEORDER_H" prevents 
arch/mips/include/asm/byteorder.h from being pre-processed by the host 
compiler. Maybe with LLVM _ASM_BYTEORDER_H is never defined by not having 
another byteorder.h in the include chain.

> If I set CROSS_BUILD_TOOLS=1, obviously this problem goes away.
> OR, if I use defconfig (sandbox) to get everything all x86-ish and compile 
> with 
>   make -j1 V=1 tools
> ...then it compiles the tools just fine (well, it can't find openssl headers, 
> and doesn't seem to pay attention to KCFLAGS= when I try to tell it where 
> they are, but that's a different problem).
> Anyway, before I start hacking make files and what-not, thought I'd check in 
> and see if the gurus had any thoughts ?
> Thanks
> -- Ward

- Daniel

Attachment: signature.asc
Description: OpenPGP digital signature

U-Boot mailing list

Reply via email to