Help building AROS hosted on Linux ARM: AROS FORUMS

Help building AROS hosted on Linux ARM

Last updated on 12 days ago

FaroxMember

Posted 22 days ago

Hi
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:

Quote

Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic': configure: error: C compiler cannot create executables Seeconfig.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2

looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic

i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.

now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)

P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.

Thanks

Edited by Farox on 30-03-2025 03:45, 22 days ago

deadwoodAROS Dev

Posted 22 days ago

Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.

My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.

FaroxMember

Posted 22 days ago

Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.

deadwoodAROS Dev

Posted 22 days ago

For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.

1 user reacted to this post

Farox

FaroxMember

Posted 22 days ago

Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.

Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh

deadwoodAROS Dev

Posted 22 days ago

I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:

#MM- linklibs-armhd : libklibs-aeabi-arm

Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.

1 user reacted to this post

Argo

FaroxMember

Posted 20 days ago

deadwood wrote:

@deadwood - I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:

#MM- linklibs-armhd : libklibs-aeabi-arm

Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.

I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...).

To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.

With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.

Edited by Farox on 01-04-2025 15:21, 20 days ago

1 user reacted to this post

deadwood

FaroxMember

Posted 16 days ago

@deadwood
I retry building the toolchain but this time i edited the configure script adding my path to the armhf section and it worked, no more need to do any changes on mmakefiles (excluding the tests on cplusplus), only remain to find how to automate the building of libaeabi.
With the toolchain built i also built the core-linux-armhf (DEBUG) (option 22) , but i found that when i run Aros bootstrap (that i found on /boot/linux/AROSBootstrap) i have this error:

./boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa698c000 - 0xb698c000 (268435456 bytes)
boot/linux/Devs/hostlib.resource: Object of the wrong type or architecture

this is the result of "file"
file ./boot/linux/Devs/hostlib.resource
./boot/linux/Devs/hostlib.resource: ELF 32-bit LSB executable, ARM, EABI5 version 1 (AROS Research Operating System), statically linked, not stripped

Edited by Farox on 07-04-2025 14:51, 14 days ago

deadwoodAROS Dev

Posted 16 days ago

Ok, I think what is going on. Check AROS/bootstrap/elfloader.c - the error comes from there. In general AROS binaries on all architectures are not real binaries but relocable objects. This is what this check is checking. However... on ARM there was an effort to change AROS binaries to real ELF executables (and your file command output proves that hostlib.resource is a real ELF executable). Now if we are lucky, all you need to do to change the check to expect ELF executable not ET_REL. If we are not lucky, hosted kernel has not been modified to work with real executables (the effort was prototyped on rPI native port I believe)

1 user reacted to this post

Farox

FaroxMember

Posted 14 days ago

#10

deadwood wrote:

@deadwood - Ok, I think what is going on. Check AROS/bootstrap/elfloader.c - the error comes from there. In general AROS binaries on all architectures are not real binaries but relocable objects. This is what this check is checking. However... on ARM there was an effort to change AROS binaries to real ELF executables (and your file command output proves that hostlib.resource is a real ELF executable). Now if we are lucky, all you need to do to change the check to expect ELF executable not ET_REL. If we are not lucky, hosted kernel has not been modified to work with real executables (the effort was prototyped on rPI native port I believe)

Maybe we are not so lucky this time...but i'm not sure about it.
i changed on elfloader.c the line:
//if (eh->type != ET_REL || eh->machine != AROS_ELF_MACHINE)
if (eh->machine != AROS_ELF_MACHINE)

to bypass the ET_REL check but now i have a segmentation error...

./boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa69fa000 - 0xb69fa000 (268435456 bytes)
Errore di segmentazione

Thanks a lot for your help.

deadwoodAROS Dev

Posted 14 days ago

#11

Well, now the fun part comes in: debugging.

Run AROS through gdb:

$ gdb ./boot/linux/AROSBootstrap

and when it breaks on SIGSEV, do

$ loadbt
$ bt

You should see stack trace of where the crash happened.

Note: if you never did this before, gdb will complain about NOT using .gdbinit file - but this file is necessary for AROS debugging to work. Follow the on-screen gdb instructions to "add" this file to "safe" files and you should be ready to go.

2 users reacted to this post

Argo, Farox

FaroxMember

Posted 13 days ago

#12

OK this is the log from GDB:

Quote

gdb ./boot/linux/AROSBootstrap
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./boot/linux/AROSBootstrap...done.
(gdb) r
Starting program: /media/farox/CDEV/arosbuilds/core-linux-amrhf-d/bin/linux-arm/AROS/boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa6a2a000 - 0xb6a2a000 (268435456 bytes)

Program received signal SIGSEGV, Segmentation fault.
0x00403364 in relocate (eh=0x417eb0, sh=0x417ee8, shrel_idx=2,
DefSysBase=4285900)
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:352
352 signed long offset = *p;
(gdb) loadbt
Checking frame #0
Undefined set logging command: "enabled on". Try "help set logging".
(gdb) bt
#0 0x00403364 in relocate (eh=0x417eb0, sh=0x417ee8, shrel_idx=2,
DefSysBase=4285900)
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:352
#1 0x00403c10 in LoadKernel (FirstELF=0x418c48, ptr_ro=0xa684a1d6,
ptr_rw=0x41d0b4, tracker_p=0xb6ffa000 "240314A", DefSysBase=4285900,
kick_end=0x0, kernel_entry=0xbefff138,
kernel_debug=0x4165d0 <Debug_KickList>
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:575
#2 0x00401968 in bootstrap (argc=1, argv=0xbefff2d4)
at /media/farox/CDEV/arosbuilds/AROS/arch/all-hosted/bootstrap/./bootstrap.c:366
#3 0x00400f48 in main (argc=1, argv=0xbefff2d4)
at /media/farox/CDEV/arosbuilds/AROS/arch/all-hosted/bootstrap/./main.c:9
(gdb)

1 user reacted to this post

Argo

deadwoodAROS Dev

Posted 12 days ago

#13

Ok, I looks like the elf loader in bootstrap code was not changed to handle real executables. If you want to experiment with it, check how mschulz tried to implement full ELF loader in arch/arm-raspi/elf.c (commits from March and April 2019). You might be able to utilize parts of that code. Alternativelly try contacting mschulz on discord - he moved away from AROS but maybe can help with some pointers.

1 user reacted to this post

Farox

FaroxMember

Posted 12 days ago

#14

Thanks a lot for your help...for the moment i want to compile with some of the fix from NinjaCowboy
https://github.com/aros-development-team/AROS/pull/621
that fixed some thinks to run on Raspberry Pi (regarding relocation).
Next i will look at commits from M. Schulz.
Thanks

1 user reacted to this post

Argo

deadwoodAROS Dev

Posted 12 days ago

#15

Oh yes, good catch, I forgot about those changes from NinjaCowboy. Hope it will out. Eventually I'd love to see ELF executables support added to both x86_64 and m68k.

2 users reacted to this post

Argo, Farox

You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.

Moderator: Administrator, Moderators

Users who participated in discussion: deadwood, Farox