Unable to build/install gcc9

I am new to Manjaro and intend to install gcc9.

I know version 9 is terribly outdated, but I have some code that I need to get running in an ancient version that will not compile with the version of gcc made available through the repository.

I tried to follow these instructions from post 40098, answer 7 (sorry I am not allowed to create links)
https://forum.manjaro.org/t/gcc9-package-build-error-failed-unknown-public-key-and-other-errors-in-build/40098/7

which I had to modify a bit to not fail immediately, resulting in these steps:

sudo pacman -Syyu
sudo pacman -S base-devel binutils libmpc doxygen python git
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3AB00996FC26A641
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys A328C3A2C3C45C06
cd $softdir
git clone https://aur.archlinux.org/gcc9.git
cd gcc9
# change the PKGBUILD (at will) in the folder
makepkg -sri

All seems to go well and the computer is busy compiling for like 2 hours until finally quitting with this message:

[...]
config.status: executing default-1 commands
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing gstdint.h commands
make[1]: Leaving directory '/soft/gcc9/src/gcc-build'
make: *** [Makefile:997: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Has anyone had any success obtaining gcc9 recently?

That is from almost 2 years ago …
Have you tried what is suggested in the pinned comment on the AUR (en) - gcc9 package page ?

1 Like

Why don’t you try to build it with pamac (or another AUR helper)?
When you use makepkg to build it - all the dependencies have to be in place already.

Make sure they are. A helper takes care of that.
makepkg by itself does not

Thank you for the suggestions! I will look into them in a minute.

In the meantime I had retried to build gcc9 simply via the Add/Remove Software GUI.
Having retrieved a bunch of gpg keys that as well seemed to work, but after 1.5 hours of building the procedure exited with this message:

checking whether the target supports weakref... yes
checking whether the target can unlink an open file... yes
checking whether the target has CRLF as line terminator... no
configure: updating cache ./config.cache
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libgfortran.spec
config.status: creating config.h
config.status: executing default-1 commands
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing gstdint.h commands
make[1]: Leaving directory '/var/tmp/pamac-build-bastian/gcc9/src/gcc-build'
make: *** [Makefile:997: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

mh, so I tried to install the AUR gcc9 package that you linked through the pamac gui.
That failed as well.

I guess you are referring to this comment?

The package fails to build with lto enabled. This option is enabled by default on devtools, and may be enabled by the user in makepkg.conf. You should explicitly disable lto by adding ‘!lto’ to the ‘options’ array like is done by repository gcc, […]

So I’ll try to set that lto-option in PKGBUILD and then build outside pamac using makepkg, right?

I’m referring to the comment made by @jonathon

ok, first, when building via makepkg (initial post) in the PKGBUILD file line 19 read options=(!emptydirs !lto).

Second,

I have no idea what I am supposed to do in order to not use a clean chroot but to use an AUR helper instead.

I’m trying to install gcc8 through the pamac GUI now. My last resort would be to set up an lmod module system.

I tried the pamac GUI. It fails to build at the exact same line in the Makefile.
What other helper should I try?

yes, but further down, there is, at line 92

--enable-lto \

I don’t know whether these cancel each other
and I also can’t help further as of now - perhaps I’ll try building just to see the context of the final error.

You could use docker with a distro base that has this version natively, e.g., Ubuntu 20.04 has 9.4.0.

If that’s feasible for you, I recommend this path.

Is TO USE a clean chroot and NOT an AUR helper …
From the archived forum
https://archived.forum.manjaro.org/t/building-a-clean-chroot-with-pkg/44348/5

Also helpful to read DeveloperWiki:Building in a clean chroot - ArchWiki

FYI, we no longer use buildpkg and it’s not maintained anymore. We use chrootbuild from manjaro-chrootbuild now. A lot of the same command options are the same as buildpkg like in the example in the linked post.

1 Like

uh, interesting. So I do

git clone https://aur.archlinux.org/gcc9.git
sudo chrootbuild -c -p gcc9

and that creates an entire gnu/linux root tree in /var/lib/chrootbuild

Well, I’m excited if it works.

I don’t like that chrootbuild needs sudo.
It does so even if I choose another build directory with the -r option.
I guess it needs sudo to install prerequisites, if any.
Can I be sure that it does not mess with my system other than installing prerequired software?

I want to provide gcc9 for an isolated task (in addition to the default gcc) and not modify my main system.

A chroot is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. This modified environment is called a chroot jail .

chroot - ArchWiki

Nope, that does not succeed either. It compiles for like 2 hours then quits with

[...]
libtool: link: ar rc .libs/libitm.a  aatree.o alloc.o alloc_c.o alloc_cpp.o barrier.o beginend.o clone.o eh_cpp.o local.o query.o retry.o rwlock.o useraction.o util.o sjlj.o tls.o method-serial.o method-gl.o method-ml.o x86_sse.o x86_avx.o futex.o
libtool: link: ranlib .libs/libitm.a
libtool: link: ( cd ".libs" && rm -f "libitm.la" && ln -s "../libitm.la" "libitm.la" )
make[4]: Leaving directory '/build/gcc9/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[3]: Leaving directory '/build/gcc9/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[2]: Leaving directory '/build/gcc9/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[1]: Leaving directory '/build/gcc9/src/gcc-build'
make: *** [Makefile:997: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Building package [gcc9] failed.
      Cleaning up.

I wish the error message would print the location of the Makefile …

There is a Makefile in /var/lib/chrootbuild/build/gcc9/src/gcc-build, I assume that’s the one.
And there is a config.log, too.

Both don’t give me a clue. I can provide them through some cloud-service if anyone would be willing to inspect them.

Ah this is frustrating

I must admit I have never worked with docker images. Will I have to compile my application inside some docker environment, too? That wouldn’t be very practical.

I feel like a module system is more my thing.

It’s something with glibc 2.36, so until something is fixed in both PKGBUILDs, they won’t build.

Depends on how firm you are with docker. But if you have never used it, it might not be worth the time.

I tried to install gcc via spack

but that fails with the same error

[...]
libtool: link: ranlib .libs/libitm.a
libtool: link: ( cd ".libs" && rm -f "libitm.la" && ln -s "../libitm.la" "libitm.la" )
make[4]: Leaving directory '/tmp/bastian/spack-stage/spack-stage-gcc-9.5.0-3a6ryytdjitmnqokyl635p4uadxuv5e4/spack-src/spack-build/x86_64-pc-linux-gnu/libitm'
make[3]: Leaving directory '/tmp/bastian/spack-stage/spack-stage-gcc-9.5.0-3a6ryytdjitmnqokyl635p4uadxuv5e4/spack-src/spack-build/x86_64-pc-linux-gnu/libitm'
make[2]: Leaving directory '/tmp/bastian/spack-stage/spack-stage-gcc-9.5.0-3a6ryytdjitmnqokyl635p4uadxuv5e4/spack-src/spack-build/x86_64-pc-linux-gnu/libitm'
make[1]: Leaving directory '/tmp/bastian/spack-stage/spack-stage-gcc-9.5.0-3a6ryytdjitmnqokyl635p4uadxuv5e4/spack-src/spack-build'
make: *** [Makefile:996: all] Error 2

https://github.com/spack/spack/issues/32286

I tried to use the compilers installed with conda

conda install -c conda-forge "gcc<10" gfortran c-compiler  cxx-compiler

They come precompiled and unfortunately they produce new errors when trying to use them.