Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: xenodius on December 21, 2020, 09:32:17 PM
-
Hello, I see gcc.tcz contains gfortran however, when trying to compile scipy it is not recognized. So, I set out to compile just gfortran with gcc... I haven't compiled anything on linux before.
My first try, I ran out of memory. So I tried compiling on the 2nd partition (mmcblk0p2, ~60gb) which appeared to configure;
sudo git clone https://gcc.gnu.org/git/gcc.git
sudo ./contrib/download_prerequisites
sudo tar -xvf gmp-6.1.0.tar.bz2
sudo tar -xvf mpc-1.0.3.tar.gz
sudo tar -xvf mpfr-3.1.4.tar.bz2
sudo /mnt/mmcblk0p2/build/gcc/configure --prefix=/mnt/mmcblk0p2/build/gcc --enable-languages=c,fortran
sudo make -j4 DESTDIR=/mnt/mmcblk0p2/build/gcc-build
however, make eventually returned:
checking how to run the C preprocessor... /lib/cpp
configure: error: in `/mnt/mmcblk0p2/build/gcc-build/armv7l-unknown-linux-gnueabihf/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
make[2]: *** [Makefile:20136: configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory '/mnt/mmcblk0p2/build/gcc-build'
make[1]: *** [Makefile:25512: stage1-bubble] Error 2
make[1]: Leaving directory '/mnt/mmcblk0p2/build/gcc-build'
make: *** [Makefile:1001: all] Error 2
Seems like I'm missing something needed to compile C, or a path to it? I have gcc, gmp, mpfr, and mpc tcz's... however, gcc would not configure without the source for gmp, mpfr, and mpc, detecting gmp but not mpfr/mpc the first try, so I grabbed them all via './contrib/download_prerequisites' as above before I ran out of memory and tried it on mmcblk0p2.
I've attached the config.log, which included some surprisingly kinky commentary that may be irrelevant but I feel compelled to draw attention to below. Easter egg?
conftest.c:17:5: error: unknown type name 'choke'
17 | choke me
| ^~~~~
........
| {
| #if MPFR_VERSION < MPFR_VERSION_NUM(3,1,6)
| choke me
| #endif
| ;
| return 0;
| }
configure:7812: result: buggy but acceptable
-
Hi xenodius
... I have gcc, gmp, mpfr, and mpc tcz's... however, gcc would not configure without the source for gmp, mpfr, and mpc, ...
You might need the dev files (gmp-dev.tcz, mpfr-dev.tcz, and mpc-dev.tcz), not the source packages.
-
When you are reporting a bug, please report OS release version and the version, packing date of extension.
-
To compile gcc you need something like:
$ tce-load compiletc mpc-dev python3.8
-
Hello, I see gcc.tcz contains gfortran however, when trying to compile scipy it is not recognized. So, I set out to compile just gfortran with gcc... I haven't compiled anything on linux before.
My first try, I ran out of memory. So I tried compiling on the 2nd partition (mmcblk0p2, ~60gb) which appeared to configure;
sudo git clone https://gcc.gnu.org/git/gcc.git
sudo ./contrib/download_prerequisites
sudo tar -xvf gmp-6.1.0.tar.bz2
sudo tar -xvf mpc-1.0.3.tar.gz
sudo tar -xvf mpfr-3.1.4.tar.bz2
sudo /mnt/mmcblk0p2/build/gcc/configure --prefix=/mnt/mmcblk0p2/build/gcc --enable-languages=c,fortran
sudo make -j4 DESTDIR=/mnt/mmcblk0p2/build/gcc-build
I would add that you shouldn't do any of this as root. You are also downloading a git checkout which will likely be the development branch and possibly broken, therefore try with the current stable 10.2 release:
https://gcc.gnu.org/mirrors.html
e.g.
ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-10.2.0/gcc-10.2.0.tar.gz
-
I would add that you shouldn't do any of this as root.
I had to use root I think because of my permissions on /mnt/... worked without it in /tmp/, just ran out of space that way. I tried the 10.2 branch this morning, was excited when it ran fine for >15 minutes... but I just got back 11 hours later and it appears to be looping the exact same lines every 7-8 seconds... Pi is still working based on temp. I expected a few hours, but now wondering if it might go forever. :o
To bmarkus, Juanito, and Rich,
I should have been clearer on those details, sorry-- I think I have all that loaded. Relevant onboot packages:
piCore 11.0beta2, kernel 4.19.81-v7L on Pi4B
gcc, gcc_base-dev, gcc_libs, gcc_libs-dev: 9.2.0
compiletc 9.0
mpc, mpc-dev 1.1.0
mpfr, mpfr-dev 3.1.4
make 4.2.1
cmake 3.15.5
autoconf 2.69
automake 1.16.2
python3.8
-
Hi xenodius
Looking at this:
http://tinycorelinux.net/6.x/armv6/tcz/gcc.tcz.list
I see this:
usr/local/bin/cpp
usr/local/bin/armv6l-unknown-linux-gnueabihf-gfortran
usr/local/bin/armv6l-unknown-linux-gnueabihf-gcc-ar
usr/local/bin/gcc
usr/local/bin/gcc-nm
usr/local/bin/armv6l-unknown-linux-gnueabihf-gcc-4.9.2
usr/local/bin/armv6l-unknown-linux-gnueabihf-gcc-ranlib
usr/local/bin/armv6l-unknown-linux-gnueabihf-g++
usr/local/bin/armv6l-unknown-linux-gnueabihf-gcc-nm
usr/local/bin/armv6l-unknown-linux-gnueabihf-gcc
usr/local/bin/gcc-ar
usr/local/bin/gcc-ranlib
usr/local/bin/c++
usr/local/bin/armv6l-unknown-linux-gnueabihf-c++
usr/local/bin/g++For every long version of a command there is a short version, except except gfortran.
Hello, I see gcc.tcz contains gfortran however, when trying to compile scipy it is not recognized. ...
If you do this:
sudo cp -a /tmp/tcloop/gcc/usr/local/bin/armv6l-unknown-linux-gnueabihf-gfortran /usr/local/bin/gfortranDoes it work then?
-
Hey Rich, a short version sounds great but I'd be happy with anything that works. Once I setup all these dependencies and backup the image I should be good more or less indefinitely. I tried copying just one and both of:
usr/local/bin/armv7l-unknown-linux-gnueabihf-gfortran
usr/local/bin/gfortranto /usr/loca/bin/gfortran, from 7.x armv7 repo (I am on 11x but 7x was the latest repo I found containing these fortran files). To compile scipy I need BLAS then LAPACK, which themselves need GFortran, each time I tried to compile OpenBLAS-0.3.13 I got:
gfortran: error trying to exec 'f951': execvp: No such file or directory
gfortran: error trying to exec 'make[2]: *** [<builtin>: sgbbrd.o] Error 1
make[2]: *** Waiting for unfinished jobs....
f951': execvp: No such file or directory
make[2]: *** [<builtin>: spotrf2.o] Error 1
gfortrangfortran: error trying to exec 'f951': execvp: No such file or directory
: error trying to exec 'f951': execvp: No such file or directory
make[2]: *** [<builtin>: sgetrf2.o] Error 1
make[2]: *** [<builtin>: sgbcon.o] Error 1
make[2]: Leaving directory '/mnt/mmcblk0p2/build/blas/OpenBLAS-0.3.13/lapack-netlib/SRC'
make[1]: *** [Makefile:27: lapacklib] Error 2
make[1]: Leaving directory '/mnt/mmcblk0p2/build/blas/OpenBLAS-0.3.13/lapack-netlib'
make: *** [Makefile:244: netlib] Error 2
Googling found some cases on MAC OSx with this error, that was fixed by linking f951 in the PATH to the binary of gfortran or reinstalling gcc/gfortran, but I have not been able to find out how to do this in piCore. Googling about linux generally I see that there are lots of types of links (hard, soft, symbolic?) and I'm not sure which is needed here. This is new territory for me but I didn't expect this much trouble since gcc has already been compiled for every version of piCore.
-
Hi xenodius
... to /usr/loca/bin/gfortran, from 7.x armv7 repo (I am on 11x but 7x was the latest repo I found containing these fortran files). ...
You can't copy binaries from one version of gcc to another.
When you said:
Hello, I see gcc.tcz contains gfortran however, when trying to compile scipy it is not recognized. ...
I thought you meant it contained something like:
usr/local/bin/armv6l-unknown-linux-gnueabihf-gfortranbut was missing:
usr/local/bin/gfortranwhich is just a renamed copy (or maybe a hardlink).
-
Here I was thinking the longshot was 11x vs. 7x piCore, but it makes sense that'd be a sure break.
I suggested gcc.tcz contains gfortran because with the 11x gcc.tcz, gcc -v returns the configuration,
./gcc-9.2.0/configure --libdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++,fortran,go --disable-multilib --disable-libstdcxx-pch --enable-cloog-backend=isl --with-isl=/usr --with-system-zlib --enable-frame-pointer --disable-bootstrap --enable-lto --with-pkgversion=piCore --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-gxx-include-dir=/usr/include/c++/9.2.0
indicating it was compiled for c, c++, fortran, and go. I'm not sure why I can't compile source that requires fortran, but the only file with 'fortran' in the name of the gcc lib is an include: usr/lib/gcc/armv7l-unknown-linux-gnueabihf/9.2.0/include/ISO_Fortran_binding.h
In the meantime I will see if maybe environmental variables or some configure flags will allow me to build fortran.
-
The x86 build notes are here: http://tinycorelinux.net/10.x/x86/tcz/src/gfortran
..and you could take a look at:
http://tinycorelinux.net/10.x/x86/tcz/gfortran.tcz.info
http://tinycorelinux.net/10.x/x86/tcz/gfortran-lib.tcz.info
On piCore, you would need something like: CC="gcc -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -Os -pipe" CXX="g++ -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -Os -pipe" ../configure --prefix=/usr/local --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib
-
Juanito, those compile notes are a gem, thank you for pointing them out!
Is the purpose of these lines:
find . -name Makefile -type f -exec sed -i 's/-g -O2//g' {} \;
find . -name Makefile -type f -exec sed -i 's/-O2 -g//g' {} \;
find . -name config.status -type f -exec sed -i 's/-g -O2//g' {} \;to replace the flags on the below variables? Just curious why this is necessary.
At any rate, no matter what I did, 'make' just looped back through the ./configure output:
tc@box:/mnt/mmcblk0p2/build/gcc/gcc-10.2.0$ sudo make -j4
make: Warning: File 'Makefile.in' has modification time 1595482727 s in the future
CONFIG_SHELL="/bin/bash" /bin/bash ./config.status --recheck
running CONFIG_SHELL=/bin/bash /bin/bash ./configure --prefix=/usr/local --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --enable-languages=c,c++,fortran,lto --no-create --no-recursion
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking target system type... armv7l-unknown-linux-gnueabihf
..........................
configure: creating ./config.status
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/bash ./config.status
config.status: creating Makefile
make: Warning: File 'Makefile.in' has modification time 1595482719 s in the future
CONFIG_SHELL="/bin/bash" /bin/bash ./config.status --recheck
running CONFIG_SHELL=/bin/bash /bin/bash ./configure --prefix=/usr/local --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --enable-languages=c,c++,fortran,lto --no-create --no-recursion
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking target system type... armv7l-unknown-linux-gnueabihf
............................
configure: creating ./config.status
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/bash ./config.status
config.status: creating Makefile
I eventually realized that the reason for this loop, was that the timestamps were too old. Everything was ~1970. Somehow 'make' realized that this was older than the current time, yet simultaneously all created files still had this old timestamp. So it'd create a configuration, see it's 50 years old and decide to recreate it, see the new file is 50 years old, repeat... After setting the time with 'date', and starting over with re-extracted source it appears to be working. I knew it was some silly detail! Thank you all for your suggestions-- they are greatly appreciated, I have learned something from each of your posts here and elsewhere. I will try to configure my RTC so that the time persists accurately.
This is sort of offtopic, but about NTC updating-- It seems it takes the pi >60 seconds to connect to my wifi, so my time is never updated on boot. Is there a way to postpone the NTC time update timeout beyond 60 seconds?
-
Hi xenodius
... to replace the flags on the below variables? Just curious why this is necessary. ...
It finds and removes those 2 flags. I think those flags in the Makefile and config file might override flags you export. We typically
compile with the -Os flag (smaller executable).
... Somehow 'make' realized that this was older than the current time ...
Yes, make checks timestamps to determine what does or does not need to be rebuilt.
-
I am still getting the following error after about a half hour:
configure: error: C preprocessor "/lib/cpp" fails sanity checkSolutions to this error for other packages/distros suggested symlinking issue. The following link causes make to fail the sanity check almost immediately:
sudo ln -s /lib/cpp /usr/local/bin/cpp
In config.log, most cache variables have nothing after '=';
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
So in output variables:
CPPFLAGS=''
Based on other cases users have actually had to clear CPPFLAGS/CPP environmental variables in order to compile correctly... which makes sense, I think gcc should be using the corresponding cpp source downloaded via the download_prerequisites script, not the 9.2.0 version of cpp included in gcc.tcz. And as near as I can tell from the logs, it is. If I understand the configure operation and config.log correctly, it is clearing these environmental variables (='' in config.log output variables). Probably this is reason enough not to have tried the symlink, but since it did cause it to fail faster I think I might be on the right track and it's an issue with links/environmental variables. But nothing I've tried/adapted from similar errors in other packages/distributions has worked so far. Including clearing these environmental variables, directing to /usr/local/bin/cpp, and resetting piCore to a recent backup before I touched any environmental variables. :-[
-
Hi xenodius
I have to ask, you're not using the values shown in the CC and CXX flags supplied in this link:
http://tinycorelinux.net/10.x/x86/tcz/src/gfortran/compile_gfortran
This build script for gcc shows CFLAGS and CXXFLAGS suitable for armv7 being exported.
http://repo.tinycorelinux.net/8.x/armv7/tcz/src/gcc/gcc630.build
-
Did you check config.log in the appropriate sub-directory to see why cpp fails the sanity check?
On x86_64, for example, it is often because it cannot find the loader, /lib/ld-*
-
Hi Rich, thanks for the link. I used these CFLAGS/CXXFLAGS, since I thought I had to use armv7l for the armv8 Raspberry Pi 4 CPU on a 32-bit system. I was actually under the impression armv6xx flags would not work on armv7x but clearly that's not the case.
export CFLAGS="gcc -march=armv7l -0s -pipe"
export CXXFLAGS="g++ -march=armv7l -0s -pipe"but was configuring with only these tags:
--prefix=/usr/local --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/libSo I tried again with:
export CFLAGS="-O2 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp"
export CXXFLAGS="-O2 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp"
--prefix=/usr/local --libdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++,fortran --disable-multilib --disable-libstdcxx-pch --enable-cloog-backend=isl --with-isl=/usr --with-system-zlib --enable-frame-pointer --disable-bootstrap --enable-lto --with-pkgversion=piCore --with-arch=armv6zk --with-tune=arm1176jzf-s -with-fpu=vfp --with-float=hard --with-gxx-include-dir=/usr/include/c++/9.2.0
And make -j4 ran for about 20 minutes, then I lost SSH connection, CPU temp started to decrease, and it did not finish compiling (I left it idle for another hour before restarting)
Juanito, I saved the config.log from the root directory-- I did not for /libcpp/, admittedly I didn't realize each subfolder had it's own log and have since overwritten that build. I can try that ./configure again, but since the ./configure Rich referenced seems not to have the error I would guess I had simply not configured it appropriately.
Not sure how to diagnose a hard crash like this without an error. I do have the config.log files, but have not found anything that looks like an error yet. The CLI output from right before the crash was:
GENERIC decision tree has 3162 leafs, maximum depth 13 and a total number of 13042 nodes
removed 2119 duplicate tails
/bin/bash /mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../move-if-change tmp-gimple-match.c gimple-match.c
/bin/bash /mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../move-if-change tmp-generic-match.c generic-match.c
echo timestamp > s-match
g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-n arrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long- long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/mnt/mmcblk0p2/bu ild/gcc/gcc-10.2.0/gcc -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/. -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../inclu de -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libcpp/include -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libdecnu mber -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/mmcblk0p2/build/gcc/gcc-1 0.2.0/gcc/../libbacktrace -I/usr/include -o gimple-match.o -MT gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo gimple-match.c
g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-n arrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long- long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-unused -DHAVE_CONFIG_H -I. -I. -I/mnt/mmcblk0p2/bu ild/gcc/gcc-10.2.0/gcc -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/. -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../inclu de -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libcpp/include -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libdecnu mber -I/mnt/mmcblk0p2/build/gcc/gcc-10.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/mmcblk0p2/build/gcc/gcc-1 0.2.0/gcc/../libbacktrace -I/usr/include -o generic-match.o -MT generic-match.o -MMD -MP -MF ./.deps/generic-match.T Po generic-match.c
I am currently running headless but I'll try again with a display on it and see if I can get any additional error information. Looking at the piCore 12 aarch64 repo, looks like all the packages I care about are already there... so if I can't get any extra error info I'll try building on 12.x instead.
-
If you are looking for error messages, it would be better to use make single threaded rather than "make -j4", which interleaves terminal output.
If you're planning to create gfortran and gfortran-lib extensions to work with the existing gcc extension, then you need to use the same compiler flags and configure switches as the existing gcc and compile to the same install location (/usr/local).
I presume you are compiling on permanent storage (you will run out of ram otherwise)?
-
I was planning to just build and replace both. I actually managed to compile everything I need and test my dashboard on Rasbian Lite without any issues, but I already know I can't live with it-- piCore is bespoken for my purposes, but at least I have a working gadget until I can build everything here. Wasn't able to get any extra error info with a display-- it simply freezes right after referencing the decision tree. I'll try piCore 12 now. With all this great guidance I stand a far better shot of making it work ;D
-
With piCore12 this should work:
$ tce-load -i compiletc mpc-dev zstd-dev python3.8 texinfo
$ wget ftp://ftp.lip6.fr/pub/gcc/releases/gcc-10.1.0/gcc-10.1.0.tar.xz
$ cd gcc-10.1.0
$ mkdir build
$ cd build
$ CC="gcc -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -Os -pipe" CXX="g++ -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -Os -pipe" ../configure --prefix=/usr/local --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --libexecdir=/usr/local/lib --with-float=hard --with-fpu=vfp
$ find . -name Makefile -type f -exec sed -i 's/-g -O2//g' {} \;
$ find . -name Makefile -type f -exec sed -i 's/-O2 -g//g' {} \;
$ find . -name config.status -type f -exec sed -i 's/-g -O2//g' {} \;
$ make
$ sudo make install
-
gfortran posted to piCore-12.x armv7 repo
-
Juanito, very kind of you to go out of your way to do that! Seems like getting a toolchain is the hardest part of this process. I actually wanted to try the aarch64 version of piCore 12, so I tried to build a piCore 12.x aarch64 version using the gcc build notes from the repo-- had to use -march=armv8-a instead of armv8.1-a+crc, and use the ./download_prerequisites gcc script for source instead of flagging local gmp, mpc, and mpfr libs of the same version to avoid errors, but it seems to have worked.
Oddly on my first reboot after the make, I got a wpa_supplicant: error while loading shared libraries: libnl-3.so.200 during wifi autoconnect, which failed. It didn't happen again after a 2nd reboot and wifi now works fine again :o Did not call filetool.sh -b between setting up wifi, and making gfortran.
I would like to submit gfortran and some of the other packages I'll build, e.g. scipy, to the piCore-12.x aarch64 repo. There's a dead link to tcztools in the Creating Extensions page of the wiki that sounds very useful-- is it still around and working somewhere? If not I can use the extensive build notes (http://repo.tinycorelinux.net/12.x/aarch64/tcz/src/gcc/gcc1010.build) as a guide-- I just don't want to make a mistake in the process, some of the commands are still over my linux noob head =)
-
Are you sure that you didn’t mistype something, gcc will compile using the build notes and the gmp/isl/mpc/mpfr-dev extensions.
-
I don't think i did, I tried it cut/pasted via SSH first changing only enable-languages then repeated it directly on the pi;
export CFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a53 -use-ld=gold -lpthread"
export CXXFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a53 -use-ld=gold"
../configure \
--libdir=/usr/lib \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--enable-c99 \
--enable-long-long \
--enable-clocale=gnu \
--enable-languages=fortran \
--disable-multilib \
--disable-libstdcxx-pch \
--enable-cloog-backend=isl \
--with-isl=/usr/local \
--with-mpfr=/usr/local \
--with-gmp=/usr/local \
--with-mpc=/usr/local \
--with-system-zlib \
--enable-frame-pointer \
--disable-bootstrap \
--enable-lto \
--with-pkgversion=piCore64 \
--with-arch=armv8-a+crc \
--enable-fix-cortex-a53-843419 \
--with-gxx-include-dir=/usr/include/c++/10.1.0
Consistently got this error on make:
sh: AARCH64_FL_CRC: unknown operand
Unknown extension used in --with-arch=armv8-a+crc
And got the same error with these flags (http://forum.tinycorelinux.net/index.php/topic,24196.msg153344.html#msg153344) and tuning to my pi4b cpu:
export CC="gcc -march=armv8-a+crc -mtune=cortex-a72 -Os -pipe"
export CXX="g++ -march=armv8-a+crc -mtune=cortex-a72 -Os -pipe -fno-exceptions -fno-rtti"
OR
export CFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -use-ld=gold -lpthread"
export CXXFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -use-ld=gold
The 'mismatch' error I got from mpfr only happened when specifying mpfr|gmp|mpc=/usr/local in configure after running download_prerequisites, I loaded it in one of several tests with the CRC error. Re-extracted and rebuilt with mpfr|gmp|mpc=/usr/local instead of same source using --with-arch=armv8-a option successfully.
The gcc documentation states: The value ‘armv8.1-a’ implies ‘armv8-a’ and enables compiler support for the ARMv8.1-A architecture extension. In particular, it enables the ‘+crc’, ‘+lse’, and ‘+rdma’ features.
So for one test I tried replacing armv8-a+crc with armv8.1-a+crc in CFLAGS/CXXFLAGS/configure. This returned a similar error:
sh: AARCH64_FL_CRC: unknown operand
Unknown extension used in --with-arch=armv8.1-a+crc
Obviously it has worked so there's probably some difference in our setup, but as best I can google the Cortex-A72 on my pi4B doesn't support armv8.1 and gcc doesn't seem to support +crc with anything less than armv8.1 so I think it's okay. I'll try to compile scipy with it and run some tests on the package to double check before I send it in.
-
If your build does not use the gmp, isl, mpc and mpfr extensions from the repo and the same compiler flags then there is the risk of problems with applications compiled with it.
I'm note sure where you got the build notes from, but using the last build of gcc from here: http://tinycorelinux.net/12.x/aarch64/releases/RPi/src/toolchain/compile_tc12_aarch64 gives the following configure switches: LD=ld CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -Os -pipe" CXXFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -Os -pipe" ../configure --prefix=/usr/local --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --enable-fix-cortex-a53-843419 --libexecdir=/usr/local/lib --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local
..and it compiles natively without errors.
-
As always you're right, I got them from here (http://repo.tinycorelinux.net/12.x/aarch64/tcz/src/gcc/gcc1010.build). The build I tested only lacked the +crc flag (Realized I could use local gmp, mpc, and mpfr extensions once I removing the source from download-prerequisites, leftover from testing other flags) but doesn't seem to work properly.
I will try using that toolchain log, and I am also putting the gfortran package you so kindly compiled on the armv7l repo to work so I can share plug-and-play ready images with broader compatibility <3
-
gfortran posted to aarch64 repo
-
Please let me know where to send your cake. ;D ;D ;D Thank you so much!