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?
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
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 .
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
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.
Trying to install with Lmod/EasyBuild
but here I am stuck due to dependencies not available:
Issue at the easybuild github page: Easybuild complains about rdma-core-dependencies even though they are present · Issue #818 · easybuilders/easybuild · GitHub