This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AW: Cross compiling Newlib for ARM in Cygwin


Greetings,

In hopes to clarify the situation with build, host and target.

Build refers to the system you are compiling in. In your case, cygwin on
some variation of x86. Host refers to the system where you will be
running your toolchain. Target refers to the machine where the final
compiled binary you build with your toolchain ends up running.

For example, if you want to build a toolchain on an x86_64 GNU/Linux
machine to compile programs in a MIPS32 little endian machine under
GNU/Linux so that the programs run on an ARM machine under GNU/Linux,
then you would issue

./configure --build=x86_64-unknown-linux-gnu \
	--host=mipsel-linux \
	--target=arm-none-linux-gnueabi

The "uknown" above in the compiler "triplet" refers to the vendor.
Sometimes, the vendor field has an effect on the machine code generation
for the toolchain. For example, when building gcc for the SPARC target,
if leon3 is given in the vendor field, gcc will build the software
floating point libraries for SPARC and assume software floating point. I
believe newlib will build the leon3 portion of libgloss anlongside
libleon and friends [have not tried this with recent versions]. If any
of the parameters is not specified, then they are determined by the
config.guess script, which resolves them to your host. Herein the issue
you were having: config.guess was determining them to be that of your
current system but the configure script was calling an ARM compiler.

The situation with newlib is a bit weirder since newlib is [usually] not
used in a hosted system [systems with an underlying operating system,
shared libraries and all that stuff]. When cross-compiling newlib, the
--host parameter is usually omitted because it has no effect, the
--target parameter determines the architecture of the binaries that get
generated. The arm-none-eabi target is a bare-metal target [no
underlying OS], thus the --host parameter can be safely omitted.

Hope this clarifies things a bit for you.

Cheers,
Orlando.

On 03/22/2016 04:55 PM, Schwarz, Konrad wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> 
>> I have downloaded newlib-cygwin in directory ./newlib-cygwin .  I
>> create a directory ./newlib-cygwin-arm, and
>>
>> $ export CC=arm-none-eabi-gcc
>> $ cd newlib-cygwin-arm
>> $ ../newlib-cygwin/configure
> 
> Further experimentation shows that
> 
> $ CC=gcc
> $ ../newlib-cygwin/configure --target=arm-none-eabi-gcc
> 
> seems to be the right thing to do.
> 
> I have to say that I find newlib/README confusing:
> Section "The Build, Host, and Target Concepts in newlib"
> states that "the target concept does not apply to [newlib] ...
> gcc's target platform is newlib's host platform,
> and, as mentioned before, newlib has no concept of target",
> but the top-level configure script requires the --target=
> argument.  I was misled by this to set host to arm-none-eabi.
> 
> I think the presentation could be improved by adding a sentence
> to the effect of "To compile newlib for a host x, add
> --target=x when invoking the top level configure script."
> 
> Regards
> 
> Konrad Schwarz
> 

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]