13.09.2015 05:41, Mark H Weaver пишет:
> Andrei Borzenkov <arvidjaar@gmail.com> writes:
>
>>> ld: /tmp/conftest-efc530.o: compiled for a big endian system and target is little endian
>>> ld: /tmp/conftest-efc530.o: endianness incompatible with that of the selected emulation
>>
>> This is the same problem we had on powerpc. Your binutils are set to
>> use little-endian output by default; we need to explicitly enable
>> either big or little endian in this case as well. Could you try
>> attached patch to verify?
>
> I'm glad to report that with your new patch, GRUB successfully builds on
> GuixSD mips64el with TARGET_CC=clang.  I haven't yet tried booting it
> though.
>

Did you have chance to test whether compiled grub actually work?

>>> Your patch works for me with gcc, although config.log shows this warning
>>> when building the test program in your new code with the correct flags
>>> for gcc (-mabi=32):
>>>
>>>     ld: warning: cannot find entry symbol __start; defaulting to 00000000004000d0
>>>
>>
>> Well, I just reused existing checks in this case; we worry about it later.
>
> Okay.  I guess the name of the start symbol depends on the platform and
> linker.  E.g. boot/mips/loongson/fwstart.S has this:
>
> --8<---------------cut here---------------start------------->8---
> 	.global start,_start,__start
> start:
> _start:
> __start:	
> --8<---------------cut here---------------end--------------->8---
>
> Other platforms have only '_start', or both 'start' and '_start'.
>
>>> I also worry that linking an O32 executable might be fragile on a pure
>>> non-multilib N32 system such as GNU Guix, where we lack even the gcc
>>> runtime library (libgcc_s) for O32.  For now it seems to work, but I
>>> wonder if it might be more robust to do the test compilation with -c and
>>> -freestanding?
>>>
>>
>> It is using -nostdlib; is it not enough?
>
> The warning above makes me doubt the portability and future-proofness of
> the link step of this test.  This problem could be avoided entirely by
> omitting the link step.  The link step serves no purpose in this test,
> and is a potential source of portability problems.
>

This step helped us to catch endianness mismatch; we want to ensure in 
this case that full toolchain works to produce final binary.

> Having said that, if you prefer to keep the link step, I guess it will
> probably be okay in practice to define 'start', '_start', and '__start'
> as above.  Do as you think best.
>


Please test two attached patches. They separate o32 test from endianness 
test. I compile-tested them using cross-binutils for mips and 
powerpc64le to compile for mipsel and powerpc. The first patch also adds 
additional _start and __start symbols to endianness tests to avoid 
compiler warnings.

I am interested in both native and cross compilation - i.e. please test 
for both --target=mipsel and --target=mips both with gcc and clang. 
config.log from all runs would be interesting even for successful cases.