Re: Cross Compiling for riscv64

[Kai Ruottu <kai.ruottu@wippies.com>]

[-- Attachment #1: Type: text/plain, Size: 4707 bytes --]

Sagar Acharya via Gcc-help kirjoitti 14.2.2023 klo 13.37:
> I built binutils and added variables
> AR , etc. for configuring
>
> Configured with
> ./configure --target=riscv64-unknown-elf
> make
As told on the GCC page configuring in the main GCC source directory is 
not recommended (https://gcc.gnu.org/install/configure.html) :

------------------ clip ----------------------------------
We use srcdir to refer to the toplevel source directory for GCC; we use 
objdir to refer to the toplevel build/object directory.

.......

First, we *highly* recommend that GCC be built into a separate directory 
from the sources which does *not* reside within the
source tree. This is how we generally build GCC; building where srcdir 
== objdir should still work, but doesn’t get extensive
testing; building where objdir is a subdirectory of srcdir is unsupported.
------------------ clip ----------------------------------

> I already have a preinstalled package aarch64-linux-musl-gcc . Kindly help.
Where this package could be downloaded?  The "Void Linux" pages don't 
include any GCC package for native/cross aarch64.
Only the runtime libraries in their ROOTFS/PLATFORMFS packages :

[root@AthlonXP2 aarch64-void-linux-musl]# ls
bin   dev  home  lib32  media  opt   root  sbin  tmp  var
boot  etc  lib   lib64  mnt    proc  run   sys   usr
[root@AthlonXP2 aarch64-void-linux-musl]# cd usr
[root@AthlonXP2 usr]# ls include
f2fs_fs.h  gawkapi.h  iproute2  quota.h

[root@AthlonXP2 usr]# ls lib
depmod.d                         libnftnl.so.11.6.0
dhcpcd                           libnl-3.so.200
dracut                           libnl-3.so.200.26.0
e2initrd_helper                  libnl-cli-3.so.200
engines-1.1                      libnl-cli-3.so.200.26.0
gawk                             libnl-genl-3.so.200
ld-musl-aarch64.so.1             libnl-genl-3.so.200.26.0
libacl.so.1                      libnl-idiag-3.so.200
libacl.so.1.1.2301               libnl-idiag-3.so.200.26.0
libarchive.so.13                 libnl-nf-3.so.200
libarchive.so.13.6.1             libnl-nf-3.so.200.26.0
libattr.so.1                     libnl-route-3.so.200
libattr.so.1.1.2501              libnl-route-3.so.200.26.0
libblkid.so.1                    libnl-xfrm-3.so.200
libblkid.so.1.1.0                libnl-xfrm-3.so.200.26.0
libbz2.so.1                      libpamc.so.0
libbz2.so.1.0                    libpamc.so.0.82.1
libbz2.so.1.0.8                  libpam_misc.so.0
libcap-ng.so.0                   libpam_misc.so.0.82.1
libcap-ng.so.0.0.0               libpam.so.0
libcap.so.2                      libpam.so.0.85.1
libcap.so.2.54                   libpanelw.so.6
libcom_err.so.2                  libpanelw.so.6.3
libcom_err.so.2.1                libpcap.so.1
libcrypto.so.1.1                 libpcap.so.1.10.1
libc.so
...............

There should be some but clicking their download links results to nothing :(

I found some other package for a 'i686-linux-gnu' hosted "statically 
built" cross GCC for 'aarch64-linux-musl' target
which had both development headers and libraries and that enabled me to 
build own cross-GCC to 'aarch64-linux-musl'
target. And then to build 'aarch64-linux-musl'-hosted stuff like this 
GCC, configured with :

../configure --build=i686-linux-gnu --host=aarch64-linux-musl 
--target=riscv64-elf --prefix=/opt/cross --libdir=/opt/cross/lib 
--libexecdir=/opt/cross/lib --enable-languages=c,c++ --disable-shared 
--disable-threads --disable-nls --disable-multilib --disable-libgcj 
--disable-libffi --enable-languages=c,c++ --with-newlib 
--with-gxx-include-dir=/opt/cross/include/c++/11.3 
--enable-version-specific-runtime-libs --program-prefix=riscv64-elf- 
--program-suffix=-11

BUT this ISN'T for the same host as the "Void Linux for aarch64 with 
musl"!  How good the binary compatability is
between different distros I have no clue.  Producing the same 
'riscv64-elf' targeted GCC with the gcc-12.2.0 sources
(and with 'newlib') just now succeeded when writing this...

One advice from me would be to consider using a "factory" instead of 
"garage" for producing this kind of stuff.
My old 2,8 MHz AthlonXP PC may sound "old and slow" but in my 70 years 
age its speed is enough for me.