Re: Big-endian in combined one-pass build

[Drasko DRASKOVIC <drasko dot draskovic at gmail dot com>]

Hi Jeff,
Thank you very much for this clarification.

I have some additional question at this point :

On Mon, Jan 24, 2011 at 11:10 PM, Jeff Johnston <jjohnstn@redhat.com> wrote:
> On 01/24/2011 09:52 AM, Drasko DRASKOVIC wrote:
>> Questions are :
>> 1) Why is this happening and how to force newlib to compile in BE mode ?
>
> Normally, newlib is built with a target and using multilib. ?Gcc then
> reports the permutations to build newlib with. ?When you don't use multilib,
> then newlib gets built with the default options and whatever options you
> override. ?If the default for arm-elf is to be LE, then that's what you end
> up with.
I have not found how to pass GCC options to be BE. So I used armeb-elf
target, which seems only way to force GCC to BE.
However, I noticed that newlib has no support for armeb-elf atrget. is
this correct ?

There is some patch I found to force armeb-elf target in newlib :
http://sourceware.org/ml/newlib/2008/msg00698.html.
However, toolchain produced in that way (multilib disabled), although
capable to link well my software, it is creating binaries that do not
function well.
Is this patch incorrect ?

>
> No one has ever requested or added armeb-elf as a newlib target.
That is strange, considering that Crosstool disables multilib and
forces armeb-elf target when BE is selected...
So, basically this target does not exist and mentioned patch is risky ?

>
>> 2) Can --with-endian=big flag work even if I disabled multilib (i.e.
>> is multilib necessary for BE mode build ?)
>
> By your test results, the with-endian flag is not being used to set
> compilation flags passed to newlib. ?Newlib doesn't interpret or do anything
> with the --with-endian setting.

Yes, it seems like that. With multilib enabled I forced
--enable-biendian, which produced BE libs. They compile binaries that
seems to be fine. However patched newlib with armeb-elf target
produced bad binaries.

>
>> 3) Do I always have to use armeb-elf instead of arm-elf target when
>> multilib is disabled
>
> If you don't override the compilation flags manually, then yes.

OK, that would mean calling "make" with TARGET_CFLAGS variable set
correctly, right ? Would that be sufficient, or something else should
be changed in the code before ?

>
>> 4) Do I have to use make CFLAGS_FOR_TARGET="-mbig-endian -msoft-float"
>> CCASFLAGS="-mbig-endian -msoft-float" when calling GCC (with newlib
>> combined, one-pass) build to force Newlib to compile in big-endian
>> mode ?
>>
>
> Actually, for newlib, use TARGET_CFLAGS="-mbig-endian -msoft-float". You
> might require the CFLAGS_FOR_TARGET to ensure that other target libs are
> built with the same options (e.g. libgcc).

My question here is : would TARGET_CFLAGS="-mbig-endian -msoft-float"
to affect C++ part also (i.e. would this produce BE C++ libs) ?

Can you please clarify these variables in a little more detail, as it
seems to be crucial :
1) What would be difference between TARGET_CFLAGS and
CFLAGS_FOR_TARGET, and what is the role of the CCASFLAGS ?
2) Both GCC with C++ supptor and newlib will be compiled in combined
build calling "make" one time, and re-defining these variables. So who
will use these, GCC or Newlib, or both ? I am asking thisbecause I had
compilation breaking when issuing :
make CFLAGS_FOR_TARGET="-mbig-endian -msoft-float"
CCASFLAGS="-mbig-endian -msoft-float"

What would be correct "make" invocation then, having in mind that I'd
like to disable multilib and use toolchain to compile and link code
for big-endian ARM946ES ?


Thank you very much again for your time.

Kind regards,
Drasko