Closed gvanuxem closed 1 week ago
I forgot, it is buildable with gcc-13 or gcc-12 after, for example, a simple:
export CC=gcc-13
./configure && make
┌──(greg㉿ellipse)-[~/Git/aldor/aldor] └─$ gcc-13 --version gcc-13 (Debian 13.3.0-8) 13.3.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
┌──(greg㉿ellipse)-[~/Git/aldor/aldor] └─$ gcc-14 --version gcc-14 (Debian 14.2.0-6) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I expect that adding "CFLAGS=-Wno-error=int-conversion" will fix it, and if not, adding the same to strict_compile.m4 will do the job. I'll look into the cause to see if there's a better fix later.
I expect that adding "CFLAGS=-Wno-error=int-conversion" will fix it, and if not, adding the same to strict_compile.m4 will do the job. I'll look into the cause to see if there's a better fix later.
The two work around the conversion to int issues but, after, the build process shocks on:
make[4] : on entre dans le répertoire « /home/greg/Git/aldor/aldor/lib/axllib/src »
CC al/array.o
al/array.c: In function ‘CF34_convert’:
al/array.c:2061:16: error: returning ‘char **’ from a function with incompatible return type ‘FiPtr’ {aka ‘char *’} [-Wincompatible-pointer-types]
2061 | L1: return T1;
| ^~
al/array.c: In function ‘CF37_flatten’:
al/array.c:2191:16: error: returning ‘char **’ from a function with incompatible return type ‘FiPtr’ {aka ‘char *’} [-Wincompatible-pointer-types]
2191 | L4: return T10;
Here is the make log after your suggestions:
OK, adding "-Wno-error=incompatible-pointer-types" will fix that..
If the build still fails, then running "make -k" will push the build a bit further.
If that then fails, then run configure with "--enable-error-on-warning=no". This will mean that warnings are not treated as errrors.
"-Wno-error=incompatible-pointer-types" is nt supported by gcc but "-Wincompatible-pointer-types" is (transform them on warning only). So, the build was successful. But as with gcc-13 not all the tests passed and aldor support for FriCAS, for example, is not functional. The FriCAS build shocks on cliques.as from memory. I attached the two logs related to Aldor:
What's the error with cliques.as?
The file should probably be included in the aldor build as a test. Something to do for later.
Follow up questions - what architecture are you building on, and do you have the output from running configure?
I finally managed to find appropriate flags, I was wrong, I still had an exported CFLAGS set to -fpermissive. From the man page:
-fpermissive
Downgrade some required diagnostics about nonconformant code from errors to warnings. Thus, using
-fpermissive allows some nonconforming code to compile. Some C++ diagnostics are controlled only by this
flag, but it also downgrades some C and C++ diagnostics that have their own flag:
-Wdeclaration-missing-parameter-type (C and Objective-C only) -Wimplicit-function-declaration (C and
Objective-C only) -Wimplicit-int (C and Objective-C only) -Wincompatible-pointer-types (C and Objective-C
only) -Wint-conversion (C and Objective-C only) -Wnarrowing (C++ and Objective-C++ only) -Wreturn-mismatch
(C and Objective-C only)
The -fpermissive option is the default for historic C language modes (-std=c89, -std=gnu89, -std=c90,
-std=gnu90).
And, I was modifying a bad part of the m4 file m4/strict_compile.m4 line 21:
cfgSTRICTCFLAGS="${cfgSTRICTCFLAGS} -Wno-error=clobbered"
But this had no effect. The only way I found is exporting CFLAGS like this before the configure step:
export CFLAGS='-Wno-incompatible-pointer-types -Wno-int-conversion'
and the build was successful.
The problem which remains to me is cliques.as, again fput* issues. The Makefile has a special rule for it:
# The program 'cliques' computes cliques according to the dependencies from
# the gendeps directory. It writes a collection of Makefile variable
# assignments and Makefile targets to stdout.
CLIQUEOPTS=-mno-abbrev -mno-mactext -laldor -fx -c args=-lm
cliques: cliques.as
# $(ALDOR) $(CLIQUEOPTS) $<
$(ALDOR) $(CLIQUEOPTS) -dTRACE $<
But since the CFLAGS was not used I had to re-link gcc to gcc-13 to build it and have a working FriCAS with Aldor support. By the way, after, FriCAS compiles files using Aldor to lisp file and (compile-file ...) them so it does not matter a lot.
I also noticed that the path to unicl is hardcoded from ./configure --prefix=... so if you move the directory in which aldor was installed you break your aldor installation.
Hope that helps
See title. It is a well known issue for a lot of projects. GCC-14 is more rigorous with implicit cast.