Sage 9.4.beta3 failed to build (gcc-10.3.0)

116 views
Skip to first unread message

Kazuyoshi Furutaka

unread,
Jun 22, 2021, 10:45:30 AM6/22/21
to sage-devel
Dear all...

First of all, I'd like to thank all of you for developing and letting us use the software!

This is my first post to this group; if I did wrong (or the group is not suit to report build failures) please let me know. (and forgive me of my broken language)

First of all, I'd like to let you know that on Fedora-34 (x86_64), the simple build (configured with --prefix only) of prestine gcc-10.3.0 fails without the static version of libstdc++ library (please read this thread for details).

On Fedora-33 systems, it can build without libstdc++.a; I've tried to investigate the reason but couldn't figure out yet.

Then, even on a Fedora-34 (x86_64) system WITH libstdc++.a, the build of Sage 9.4.beta3 fails; the build of gcc-10.3.0 failed due to "gcc-multilib-multiarch.patch": without it, the build of gcc succeeds.  I'll attach the log of the failed gcc build.
On Fedora,
  MULTILIB_OSDIRNAMES =  m64=../lib64 m32=../lib mx32=../libx32
instead of
  MULTILIB_OSDIRNAMES =  m64=../lib m32=../lib32 mx32=../libx32

Sorry for just a report; I could not yet figure out how to resolve this issue (modify the patch).

Yours,
Kazuyoshi
gcc-10.3.0.log

Dima Pasechnik

unread,
Jun 22, 2021, 11:06:44 AM6/22/21
to sage-devel
On Tue, Jun 22, 2021 at 3:45 PM Kazuyoshi Furutaka
<furutaka....@gmail.com> wrote:
[...]
> First of all, I'd like to let you know that on Fedora-34 (x86_64), the simple build (configured with --prefix only) of prestine gcc-10.3.0 fails without the static version of libstdc++ library (please read this thread for details).
>
> On Fedora-33 systems, it can build without libstdc++.a; I've tried to investigate the reason but couldn't figure out yet.
>
> Then, even on a Fedora-34 (x86_64) system WITH libstdc++.a, the build of Sage 9.4.beta3 fails; the build of gcc-10.3.0 failed due to "gcc-multilib-multiarch.patch": without it, the build of gcc succeeds. I'll attach the log of the failed gcc build.
> On Fedora,
> MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib mx32=../libx32
> instead of
> MULTILIB_OSDIRNAMES = m64=../lib m32=../lib32 mx32=../libx32
>
> Sorry for just a report; I could not yet figure out how to resolve this issue (modify the patch).

it is not clear what you are trying to do.

The reasons gcc is included as a package in Sage are mostly
historical; I don't think there are many current use cases for it,
and I think it actually should be removed.
Fortunately there are enough options nowadays to source C/C++/Fortran
compilers elsewhere.
(at most, Sage might need to add some C,C++,Fortran flags)

HTH,
Dima
>
> Yours,
> Kazuyoshi
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/787484d6-5ab9-4fdd-b909-2058bbbee5den%40googlegroups.com.

Kazuyoshi Furutaka

unread,
Jun 22, 2021, 3:36:50 PM6/22/21
to sage-devel


2021年6月23日水曜日 0:06:44 UTC+9 dim...@gmail.com:
On Tue, Jun 22, 2021 at 3:45 PM Kazuyoshi Furutaka
<furutaka....@gmail.com> wrote:
[...]
> First of all, I'd like to let you know that on Fedora-34 (x86_64), the simple build (configured with --prefix only) of prestine gcc-10.3.0 fails without the static version of libstdc++ library (please read this thread for details).
>
> On Fedora-33 systems, it can build without libstdc++.a; I've tried to investigate the reason but couldn't figure out yet.
>
> Then, even on a Fedora-34 (x86_64) system WITH libstdc++.a, the build of Sage 9.4.beta3 fails; the build of gcc-10.3.0 failed due to "gcc-multilib-multiarch.patch": without it, the build of gcc succeeds. I'll attach the log of the failed gcc build.
> On Fedora,
> MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib mx32=../libx32
> instead of
> MULTILIB_OSDIRNAMES = m64=../lib m32=../lib32 mx32=../libx32
>
> Sorry for just a report; I could not yet figure out how to resolve this issue (modify the patch).

it is not clear what you are trying to do.

The reasons gcc is included as a package in Sage are mostly
historical; I don't think there are many current use cases for it,
and I think it actually should be removed.
Fortunately there are enough options nowadays to source C/C++/Fortran
compilers elsewhere.
(at most, Sage might need to add some C,C++,Fortran flags)

HTH,
Dima

I just do want to merely build Sage from source, but the build failed on current Fedora linux due to GCC build (version 11 already exits on Fedora-34).
I do NOT want to do time-consuming compile of GCC and the SPKGs dependent on it for Sage because most of them are ALREADY on our systems as rpm packages, but Sage try to do so but only to fail to do one of them.
At first, I tried to figure out why the Sage-build can NOT find the GCC on my Fedora; it is because my GCC is too NEW and so the Sage-build is compiling the older GCC and a huge number of its dependent packages.
So I'm very happy if someone modify the Sage-build so that Sage does NOT try to build GCC and its dependent (if its on a system) ASAP.

Yours,
Kazuyoshi

Kazuyoshi Furutaka

unread,
Jun 22, 2021, 3:36:50 PM6/22/21
to sage-...@googlegroups.com


2021年6月23日(水) 0:06 Dima Pasechnik <dim...@gmail.com>:
On Tue, Jun 22, 2021 at 3:45 PM Kazuyoshi Furutaka
<furutaka....@gmail.com> wrote:
[...]
> First of all, I'd like to let you know that on Fedora-34 (x86_64), the simple build (configured with --prefix only) of prestine gcc-10.3.0 fails without the static version of libstdc++ library (please read this thread for details).
>
> On Fedora-33 systems, it can build without libstdc++.a; I've tried to investigate the reason but couldn't figure out yet.
>
> Then, even on a Fedora-34 (x86_64) system WITH libstdc++.a, the build of Sage 9.4.beta3 fails; the build of gcc-10.3.0 failed due to "gcc-multilib-multiarch.patch": without it, the build of gcc succeeds.  I'll attach the log of the failed gcc build.
> On Fedora,
>   MULTILIB_OSDIRNAMES =  m64=../lib64 m32=../lib mx32=../libx32
> instead of
>   MULTILIB_OSDIRNAMES =  m64=../lib m32=../lib32 mx32=../libx32
>
> Sorry for just a report; I could not yet figure out how to resolve this issue (modify the patch).

it is not clear what you are trying to do.

The reasons gcc is included as a package in Sage are mostly
historical; I don't think there are many current use cases for it,
and I think it actually should be removed.
Fortunately there are enough options nowadays to source C/C++/Fortran
compilers elsewhere.
(at most, Sage might need to add some C,C++,Fortran flags)

HTH,
Dima

I once post a reply but it seems to disappear...

I just want to build Sage from source.
The sage-build try to build GCC and a huge number of its dependent packages though they're already on my system as rpm packages because GCC on Fedora is TOO NEW.
So I'm very happy if someone modify the build system to avoid the time-consuming build of GCC and its dependent!

Yours,
Kazuyoshi
--
Kazuyoshi Furutaka

Dima Pasechnik

unread,
Jun 22, 2021, 4:40:13 PM6/22/21
to sage-devel
Sage is not yet ready to be built with gcc 11, see
https://trac.sagemath.org/ticket/31786

On Tue, Jun 22, 2021 at 8:36 PM Kazuyoshi Furutaka
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANjERvf_M%3DDf25S3HKvkPhzXMxNEXGRcAbtUSU6g0J2UG6Q3CQ%40mail.gmail.com.

Kazuyoshi Furutaka

unread,
Jun 22, 2021, 5:16:21 PM6/22/21
to sage-...@googlegroups.com
On the other hand, build of gcc-10.3 failed.   Then, what to do?

Kazuyoshi

2021年6月23日(水) 5:40 Dima Pasechnik <dim...@gmail.com>:

Dima Pasechnik

unread,
Jun 22, 2021, 5:50:00 PM6/22/21
to sage-devel


On Tue, 22 Jun 2021, 22:16 Kazuyoshi Furutaka, <furutaka....@gmail.com> wrote:
On the other hand, build of gcc-10.3 failed.   Then, what to do?

use another compiler.
e.g. you can use clang

dnf install clang

then run Sages configure as follows

CC=clang CXX=clang++ ./configure

and then

make


This configuration is not tested much on Linux, but on macOS this is the compiler used in our builds.


Volker Braun

unread,
Jun 22, 2021, 6:57:10 PM6/22/21
to sage-devel
I'm running Fedora 34 and 9.4.beta3 builds fine (x86_64). It did compile the included gcc.

Kazuyoshi Furutaka

unread,
Jun 22, 2021, 7:44:28 PM6/22/21
to sage-...@googlegroups.com
😳

2021年6月23日(水) 7:57 Volker Braun <vbrau...@gmail.com>:

Dima Pasechnik

unread,
Jun 23, 2021, 4:37:42 AM6/23/21
to sage-devel
On Tue, Jun 22, 2021 at 11:57 PM Volker Braun <vbrau...@gmail.com> wrote:
>
> I'm running Fedora 34 and 9.4.beta3 builds fine (x86_64). It did compile the included gcc.
>
>
>
>
> On Tuesday, June 22, 2021 at 11:50:00 PM UTC+2 dim...@gmail.com wrote:
>>
>>
>>
>> On Tue, 22 Jun 2021, 22:16 Kazuyoshi Furutaka, <furutaka....@gmail.com> wrote:
>>>
>>> On the other hand, build of gcc-10.3 failed. Then, what to do?
>>
>>
>> use another compiler.
>> e.g. you can use clang
>>
>> dnf install clang
>>
>> then run Sages configure as follows
>>
>> CC=clang CXX=clang++ ./configure
>>
>> and then
>>
>> make
>>
>>
>> This configuration is not tested much on Linux, but on macOS this is the compiler used in our builds.

such a configuration is able to build Sage on Fedora 32, and only one
doctest fails.
It uses clang 10.0.1.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a2dc0758-8dd3-4b59-aa28-27d9d2f5e461n%40googlegroups.com.

Kazuyoshi Furutaka

unread,
Jun 23, 2021, 5:44:58 AM6/23/21
to sage-devel
Hi.

I think I got it!

On Fedora-34 (x86_64), if the glibc-devel.i686 package (which contains /lib/crti.o and so on), the following error occurs:

/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/var/tmp/sage/build/gcc-10.3.0/gcc-build/./gcc/xgcc -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/var/tmp/sage/build/gcc-10.3.0/gcc-build/./gcc/ -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/bin/ -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/lib/ -isystem /home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/include -isystem /home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/sys-include   -fno-checking -O2  -O2 -g -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER  -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -O2 -g -march=native -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library, but some functions are only in"; echo "   the static library.  */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > ./libgcc_s.so
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /lib/../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc
/usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/crti.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/crtn.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:994: libgcc_s.so] Error 1
make[6]: *** [Makefile:18295: all-stage1-target-libgcc] Error 2
make[5]: *** [Makefile:22899: stage1-bubble] Error 2
make[4]: *** [Makefile:998: all] Error 2
********************************************************************************
Error building gcc-10.3.0
********************************************************************************

After removing the package, the build of gcc finished without errors and the Sage-build continues...

Then stopped at Maxima...
> cp: cannot stat 'src/binary-ecl/maxima.fas': No such file or directory
(the log attached)

Almost!

Kazuyoshi


2021年6月23日水曜日 8:44:28 UTC+9 Kazuyoshi Furutaka:
maxima-5.45.0.log

Kazuyoshi Furutaka

unread,
Jun 23, 2021, 5:49:52 AM6/23/21
to sage-devel


2021年6月23日水曜日 17:37:42 UTC+9 dim...@gmail.com:
On Tue, Jun 22, 2021 at 11:57 PM Volker Braun <vbrau...@gmail.com> wrote:
>
> I'm running Fedora 34 and 9.4.beta3 builds fine (x86_64). It did compile the included gcc.
>
>
>
>
> On Tuesday, June 22, 2021 at 11:50:00 PM UTC+2 dim...@gmail.com wrote:
>>
>>
>>
>> On Tue, 22 Jun 2021, 22:16 Kazuyoshi Furutaka, <furutaka....@gmail.com> wrote:
>>>
>>> On the other hand, build of gcc-10.3 failed. Then, what to do?
>>
>>
>> use another compiler.
>> e.g. you can use clang
>>
>> dnf install clang
>>
>> then run Sages configure as follows
>>
>> CC=clang CXX=clang++ ./configure
>>
>> and then
>>
>> make
>>
>>
>> This configuration is not tested much on Linux, but on macOS this is the compiler used in our builds.

such a configuration is able to build Sage on Fedora 32, and only one
doctest fails.
It uses clang 10.0.1.


I did the same on Fedora 34 (x86_64).
It did not finish because there were too many errors in building  pynac-0.7.27.p8...
(log attached)

Kazuyoshi
pynac-0.7.27.p8.log

Dima Pasechnik

unread,
Jun 23, 2021, 6:06:52 AM6/23/21
to sage-devel
you most probably need https://github.com/pynac/pynac/pull/375

diff --git a/ginac/numeric.h b/ginac/numeric.h
index d620660..50b2b3d 100644
--- a/ginac/numeric.h
+++ b/ginac/numeric.h
@@ -51,6 +51,7 @@
#include "ex.h"

#include <gmp.h>
+#include <limits>
#include <stdexcept>
#include <vector>
#include <iostream>

which should be in Sage soon.


> (log attached)
>
> Kazuyoshi
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/694bbf80-46d6-4603-bebb-7f9a50fbb88fn%40googlegroups.com.

Dima Pasechnik

unread,
Jun 23, 2021, 6:25:09 AM6/23/21
to sage-devel
On Wed, Jun 23, 2021 at 10:45 AM Kazuyoshi Furutaka <furutaka....@gmail.com> wrote:
Hi.

I think I got it!

On Fedora-34 (x86_64), if the glibc-devel.i686 package (which contains /lib/crti.o and so on), the following error occurs:

/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/var/tmp/sage/build/gcc-10.3.0/gcc-build/./gcc/xgcc -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/var/tmp/sage/build/gcc-10.3.0/gcc-build/./gcc/ -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/bin/ -B/home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/lib/ -isystem /home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/include -isystem /home/furutaka/work/sage/sage-9.4.beta3-git-orig-bld/local/x86_64-pc-linux-gnu/sys-include   -fno-checking -O2  -O2 -g -march=native -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER  -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -O2 -g -march=native -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library, but some functions are only in"; echo "   the static library.  */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > ./libgcc_s.so
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /lib/../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc
/usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/crti.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/../lib/crtn.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:994: libgcc_s.so] Error 1
make[6]: *** [Makefile:18295: all-stage1-target-libgcc] Error 2
make[5]: *** [Makefile:22899: stage1-bubble] Error 2
make[4]: *** [Makefile:998: all] Error 2
********************************************************************************
Error building gcc-10.3.0
********************************************************************************

After removing the package, the build of gcc finished without errors and the Sage-build continues...

Then stopped at Maxima...
> cp: cannot stat 'src/binary-ecl/maxima.fas': No such file or directory
(the log attached)

the real error is in the log:

;;; Compiling /home/furutaka/work/sage/sage-9.4.beta3-git-without-glibc-devel.i686-bld/local/var/tmp/sage/build/maxima-5.45.0/src/src/maxima-package.lisp.

;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=2

;;;

;;; End of Pass 1.

;;; Internal error:

;;;   ** Error code 1 when executing

;;; (EXT:RUN-PROGRAM "gcc" ("-I." "-I/usr/include/" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-O2" "-flto=auto" "-ffat-lto-objects" "-fexceptions" "-g" "-grecord-gcc-switches" "-pipe" "-Wall" "-Werror=format-security" "-Wp,-D_FORTIFY_SOURCE=2" "-Wp,-D_GLIBCXX_ASSERTIONS" "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" "-fstack-protector-strong" "-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1" "-m64" "-mtune=generic" "-fasynchronous-unwind-tables" "-fstack-clash-protection" "-fcf-protection" "-Wno-unused" "-Wno-return-type" "-Wno-unknown-pragmas" "-fPIC" "-D_THREAD_SAFE" "-Dlinux" "-O2" "-c" "binary-ecl/maxima-package.c" "-o" "binary-ecl/maxima-package.o")):

;;; cc1: fatal error: inaccessible plugin file /home/furutaka/work/sage/sage-9.4.beta3-git-without-glibc-devel.i686-bld/local/lib/gcc/x86_64-pc-linux-gnu/10.3.0/plugin/annobin.so expanded from short plugin name annobin: No such file or directory

;;; compilation terminated.


So it looks as if ecl is not working, because of some issue with gcc you built - annobin plugin missing.


 

Kazuyoshi Furutaka

unread,
Jun 24, 2021, 4:13:28 AM6/24/21
to sage-devel
Yes, with this patch in build/pkgs/pynac/patches/, I finally succeeded in building 9.4.beta3 from git source using clang!

Thanks, Dima-san!

The Maxima issue is not yet solved, though...

2021年6月23日水曜日 19:06:52 UTC+9 dim...@gmail.com:

Dima Pasechnik

unread,
Jun 24, 2021, 5:16:56 AM6/24/21
to sage-devel
On Thu, Jun 24, 2021 at 9:13 AM Kazuyoshi Furutaka
<furutaka....@gmail.com> wrote:
>
> Yes, with this patch in build/pkgs/pynac/patches/, I finally succeeded in building 9.4.beta3 from git source using clang!
>
> Thanks, Dima-san!
It's a pleasure.
>
> The Maxima issue is not yet solved, though...
You are talking about using gcc to build Sage, right?

At least for me, ecl uses clang if it was built with clang.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/86d550e0-8a74-4190-927d-1a7f3f4b8c71n%40googlegroups.com.

Kazuyoshi Furutaka

unread,
Jun 24, 2021, 6:41:12 AM6/24/21
to sage-...@googlegroups.com


2021年6月24日(木) 18:16 Dima Pasechnik <dim...@gmail.com>:
> The Maxima issue is not yet solved, though...
You are talking about using gcc to build Sage, right?

Yes.

 
At least for me, ecl  uses clang if it was built with clang.

Strange things are...
  • I don't think annobin is included in GCC package; it's a plugin.
  • The commands in the log at the error imply that the build tried to use GCC on the system but the compiler just built for Sage was used (confirmed in the sage-buildsh).
  • There're annobins both for GCC and CLANG.
What on earth is the GCC included as SPKG in Sage for???  Is it used to build packages at a later time?

Well... Before upgrading to Fedora-34, everything was smooth.  (But as I remember it's not so long ago when Sage-GCC was updated to version 10...)

Dima Pasechnik

unread,
Jun 24, 2021, 6:52:38 AM6/24/21
to sage-devel
On Thu, Jun 24, 2021 at 11:41 AM Kazuyoshi Furutaka
<furutaka....@gmail.com> wrote:
>
>
>
> 2021年6月24日(木) 18:16 Dima Pasechnik <dim...@gmail.com>:
>>
>> > The Maxima issue is not yet solved, though...
>> You are talking about using gcc to build Sage, right?
>
>
> Yes.
>
>
>>
>> At least for me, ecl uses clang if it was built with clang.
>
>
> Strange things are...
>
> I don't think annobin is included in GCC package; it's a plugin.
> The commands in the log at the error imply that the build tried to use GCC on the system but the compiler just built for Sage was used (confirmed in the sage-buildsh).
> There're annobins both for GCC and CLANG.
>
> What on earth is the GCC included as SPKG in Sage for??? Is it used to build packages at a later time?

It includes gfortran, which is not available on macOS from a system.
Before we started a systematic unvendoring process in
https://trac.sagemath.org/ticket/27330,
on macOS gfortran was built each time Sage was built.

It's time to get rid of the monster package, if you asked me.


>
> Well... Before upgrading to Fedora-34, everything was smooth. (But as I remember it's not so long ago when Sage-GCC was updated to version 10...)
>
> Yours,
> Kazuyoshi
> --
> Kazuyoshi Furutaka
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANjERvdV4ZOVv6RqibNnFD9KmTsBVwDuCvqcGTP7q53%3Di08gYQ%40mail.gmail.com.

Kazuyoshi Furutaka

unread,
Jun 24, 2021, 7:24:39 AM6/24/21
to sage-devel


2021年6月24日木曜日 19:52:38 UTC+9 dim...@gmail.com:
> What on earth is the GCC included as SPKG in Sage for??? Is it used to build packages at a later time?

It includes gfortran, which is not available on macOS from a system.
Before we started a systematic unvendoring process in
https://trac.sagemath.org/ticket/27330,
on macOS gfortran was built each time Sage was built.

It's time to get rid of the monster package, if you asked me.

Ah!  "Try to use as many system packages as possible"!  What a fascinating title!
This is the very reason why I started reading Calcote's "Autotools (2ed.)"!
Many of the SPKGs are already included as RPM packages in Fedora, but they are not used!  At first I thought they were left undetected by the build system (therefore I started the reading), but it is because the GCC in Fedora is too NEW and the dependent packages are built along with older GCC...

Yours,
Kazuyoshi

Kazuyoshi Furutaka

unread,
Jun 25, 2021, 6:14:17 AM6/25/21
to sage-devel


2021年6月24日木曜日 19:41:12 UTC+9 Kazuyoshi Furutaka:

2021年6月24日(木) 18:16 Dima Pasechnik <dim...@gmail.com>:
> The Maxima issue is not yet solved, though...
You are talking about using gcc to build Sage, right?

Yes.

 
At least for me, ecl  uses clang if it was built with clang.

Strange things are...
  • I don't think annobin is included in GCC package; it's a plugin.
  • The commands in the log at the error imply that the build tried to use GCC on the system but the compiler just built for Sage was used (confirmed in the sage-buildsh).
  • There're annobins both for GCC and CLANG.
Not a fundamental solution, but if configured with --with-system-ecl=no when there's a working ECL on system (that is, spkg-ecl is used to build maxima), the Sage-build will finish successful.

Kazuyoshi
Reply all
Reply to author
Forward
0 new messages