Re: aarch64 stat

[K Jski <bielsk1 at vt dot edu>]

I am working on a linux machine after all though, what does this have
to do with Newlib?

In short my goal is to be able to compile and run programs using
newlib for both x86_64 and aarch64 platforms instead of the
traditional glibc. Once sucessfully compiled, the binarys will then be
moved to run natively for what they were compiled for (aarch64 binary
will run on a aarch64 linux machine and the x86-64 binary will be run
on a x86-64 linux machine)

I built the aarch64 cross-compiler via the gcc-Linaro toolchain.
because compilation will occur on a x86-64 machine first.

On Sun, Jan 11, 2015 at 5:32 AM, Marcus Shawcroft
<marcus.shawcroft@gmail.com> wrote:
> Hi.
>
>
> On 10 January 2015 at 23:08, K Jski <bielsk1@vt.edu> wrote:
>> I am also working on using newlib for aarch64 and see that it gives a
>> crt0.o file. From reading forums, I think this should be used as the
>> startup files (vs using gcc's crt1.o and crti.o, crtn.o crtend.o)
>>
>> So my new script compiling a simple hello world for aarch64 is as follows:
>>
>> INPUT=$1
>> aarch64-linux-gnu-gcc -c -o ${INPUT%.c}_ARMObj.o $1
>> echo -e " ------------ x86 OBJECT FILE OBTAINED... \n\n\n\n"
>>
>> aarch64-linux-gnu-gcc -v -nostdlib -static -o rARM64 \
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/crt0.o
>> \
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libnosys.a
>> \
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/librdimon.a
>> \
>> ${INPUT%.c}_ARMObj.o \
>> -I/home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/include \
>> -L/home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib \
>>  /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libc.a
>> \
>>  /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libg.a
>> \
>>  /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libm.a
>> \
>>  -lc -lm
>>
>>
>> this now presents the following error:
>>
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/crt0.o:
>> In function `_start':
>> /home/bielsk1/aarch64-toolchain/libgloss_ARMbuild/aarch64/../../newlib-2.1.0/libgloss/aarch64/crt0.S:156:
>> undefined reference to `_init'
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/crt0.o:
>> In function `_cpu_init_hook':
>> /home/bielsk1/aarch64-toolchain/libgloss_ARMbuild/aarch64/../../newlib-2.1.0/libgloss/aarch64/crt0.S:228:
>> undefined reference to `_fini'
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libc.a(lib_a-exit.o):
>> In function `exit':
>> exit.c:(.text+0x30): undefined reference to `_exit'
>> /home/bielsk1/aarch64-toolchain/ARM_newlib/aarch64-unknown-linux-gnu/lib/libc.a(lib_a-fini.o):
>> In function `__libc_fini_array':
>> fini.c:(.text+0x38): undefined reference to `_fini'
>> collect2: error: ld returned 1 exit status
>>
>> so what am I missing??? Do I have to write these functions myself for aarch64?
>> Thank you for your time,
>
>
> For a bare metal environment, configure gcc to target aarch64-none-elf
> rather than aarch64-none-linux-gnu, then pass the -specs option with
> something appropriate for the platform.  For ARM's AEM or foundation
> model use:
>
> $ aarch64-none-elf -specs=aem-ve.specs hello-world.c
>
> For qemu:
>
> $ aarch64-none-elf -specs=rdimon.specs hello-world.c
>
> For another platform rdimon.specs is probably a good starting point.
>
> Cheers
> /Marcus