Fedora Account System
Red Hat Associate
Red Hat Customer
I cannot compile any Algol 68 program with the new frontend introduced in GCC 16. See steps below for the error and steps to reproduce. It looks like that is because libga68.so is completely lacking symbols. $ objdump -t /usr/lib64/libga68.so.2.0.0 /usr/lib64/libga68.so.2.0.0: file format elf64-x86-64 SYMBOL TABLE: no symbols Reproducible: Always Steps to Reproduce: 1. dnf install gcc-algol68 2. echo "BEGIN\n print(("Hello, world!", new line))\nEND" > test.a68 3. ga68 -o test test.a68 Actual Results: This error message: a681: error: file ‘/usr/lib/gcc/x86_64-redhat-linux/16/libga68.so’ exists but does not contain any export data prelude: error: cannot find module ‘STANDARD’ a681: error: file ‘/usr/lib/gcc/x86_64-redhat-linux/16/libga68.so’ exists but does not contain any export data prelude: error: cannot find module ‘POSIX’ The same happens if I just compile but don't link (-c). Expected Results: Getting an executable called test test.
This is because the .a68_exports section seems to be stripped from the libga68.so (and libga68.a) run-time library. That section must be present because part of the run-time is written as Algol 68 modules.
The spec file has comments about not stripping gccgo libraries and it implies that chmoding them 644 fixes the issue: - https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_352 - https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_2455
I've added %global _find_debuginfo_opts --keep-section .a68_exports and seems in the pending gcc-16.1.1-1.fc{44,45} builds .a68_exports section is present in both libga68.so.2.0.0 and in libga68.a .
FEDORA-2026-1f4ff51dc3 (gcc-16.1.1-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1f4ff51dc3
FEDORA-2026-1f4ff51dc3 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1f4ff51dc3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1f4ff51dc3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I have version 16.1.1-1.fc44 installed now using the instructions provided but I'm still getting the same error. The .a68_exports section is still missing from the libraries. I'll provide feedback on bodhi as well once the login service is back up.
Really strange: readelf -Wa /usr/lib64/libga68.so.2.0.0 | grep export [25] .a68_exports PROGBITS 0000000000000000 00f018 000e97 00 0 0 1
Though, it is true that Fedora uses (similarly to other *.so files) /usr/lib/gcc/x86_64-redhat-linux/16/libga68.so text file with INPUT ( /usr/lib64/libga68.so.2.0.0 ) content (and similarly for 32-bit libraries). This is so that people don't complain about stale symlinks if only 64-bit or only 32-bit libraries but not both are installed. I'd say if the FE blindly assumes the *.so files must be ELF files, then it really needs to be fixed.
The updated compiler workds on on fedora 44 running on aarch64. I used the instructions from the link to install the compiler. After that compiling fails because I don't have the the static runtime library installed and the frontend defaults to that. Using the shared library works: $ ga68 hello.a68 /usr/bin/ld.bfd: cannot find -lga68: No such file or directory /usr/bin/ld.bfd: have you installed the static version of the ga68 library ? collect2: error: ld returned 1 exit status $ ga68 -shared-libga68 hello.a68 $ ./a.out Hello world! However installing the static library then breaks the shared build too, because it "downgrades" both shared and static lib packages. Running the "dnf upgrade" command to get them both from the test repo then fixes both shared and static builds: $ sudo dnf -y install libga68-static && sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1f4ff51dc3 .... $ rm -f a.out $ ga68 hello.a68 && ./a.out Hello world! $ rm -f a.out $ ga68 -shared-libga68 hello.a68 && ./a.out Hello world! Before the upgrade: $ readelf -Wa /usr/lib64/libga68.so.2.0.0 | grep export $ ga68 --version ga68 (GCC) 16.0.1 20260321 (Red Hat 16.0.1-0) Copyright (C) 2026 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. After the upgrade: $ readelf -Wa /usr/lib64/libga68.so.2.0.0 | grep export [24] .a68_exports PROGBITS 0000000000000000 010018 000e97 00 0 0 1 $ ga68 --version ga68 (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1) Copyright (C) 2026 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.
FEDORA-2026-1f4ff51dc3 (gcc-16.1.1-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Ok I a bit confused about this. The code generated by ga68 requires the modules Standard and POSIX to be present. These modules are expected in the "a68" library. The module lookup process, in this case for "ga68", works like this: 1. If a file ga68.m68 is found, it is expected to contain raw modules export data. This would basically be the raw contents of the .a68_exports section in libga68.so, or the concatenation of all the .a68_exports sections in the objects within libga68.a. 2. Otherwise, libga68.so is attempted. It is expected to be an object file, and if it contains an .a68_exports section, it is read in. 3. Otherwise, libga68.a is attempted. The export data is composed by the concatenation of the .a68_exports sections in the objects contained within the archives. 4. Otherwise, ga68.o is attempted. The export data is get from the .a68_exports section. This process is attempted at each entry in the search path. The search path is composed by OPT_I and OPT_L command line options. This is the same than gcccgo does (with .gox files rather than .m68 files. They don't have a parser for linker scripts.
We could perhaps put an ad-hoc mechanism to find the exports of the libga68.so modules, such as a configure time --with-libga68-exports-at=/path/to/multilib/libga68.2.0.0.so that could be used in the .spec file?
(In reply to Jose E. Marchesi from comment #12) > We could perhaps put an ad-hoc mechanism to find the exports of the > libga68.so modules, such as a configure time > --with-libga68-exports-at=/path/to/multilib/libga68.2.0.0.so that could be > used in the .spec file? Wouldn't the path have to change if -m32 is specified?
(In reply to Florian Weimer from comment #13) > (In reply to Jose E. Marchesi from comment #12) > > We could perhaps put an ad-hoc mechanism to find the exports of the > > libga68.so modules, such as a configure time > > --with-libga68-exports-at=/path/to/multilib/libga68.2.0.0.so that could be > > used in the .spec file? > > Wouldn't the path have to change if -m32 is specified? Hm yeah :/ I think it would be best to extract the contents of libga68.so .a68_exports into a ga68.m68 file, and put that file in some of the directories in the multilib specific search path, say in /usr/lib/gcc/x86_64-redhat-linux/16/ and /usr/lib/gcc/x86_64-redhat-linux/16/32/. ga68.m68 will take precedence to the linker script libga68.so as the source for exports.
So objcopy --dump-section .a68_exports=ga68.m68 libga68.so.*.* in each directory?
That should work, modulus bug in a68-imports.cc (I don't think we have tested this)..
Well provided the compiler proper gets a -L or a -I pointing to these directories, so they are in the search patch.
FWIW I tried with a little testcase and ga68 properly reads from foo.m68 while looking for module FOO, before attempting libFOO.so, libFOO.a and FOO.o.
The same test, but placing foo.m68 in /lib/gcc/x86_64-pc-linux-gnu/17.0.0/, also works.
(In reply to Jakub Jelinek from comment #15) > So objcopy --dump-section .a68_exports=ga68.m68 libga68.so.*.* in each > directory? Yep: $ objcopy --dump-section .a68_exports=ga68.m68 /usr/lib64/libga68.so.2.0.0 $ sudo cp ga68.m68 /usr/lib/gcc/x86_64-redhat-linux/16 $ ga68 hello.a68 -o hello-static && ./hello-static Hello world! $ ga68 -shared-libga68 hello.a68 -o hello-shared && ./hello-shared Hello world! 32-bit works too: $ sudo dnf install -y libgcc.i686 glibc-devel.i686 libatomic.i686 libga68-static.i686 libga68.i686 $ objcopy --dump-section .a68_exports=ga68-32.m68 /usr/lib/libga68.so.2.0.0 $ sudo cp ga68-32.m68 /usr/lib/gcc/x86_64-redhat-linux/16/32/ga68.m68 $ ga68 -m32 hello.a68 -o hello32-static && ./hello32-static Hello world! $ ga68 -shared-libga68 -m32 hello.a68 -o hello32-shared && ./hello32-shared Hello world! $ file hello*-* hello-shared: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c5d713b1398d64998a42eb6aad0a35cfb8a7b367, for GNU/Linux 3.2.0, not stripped hello-static: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=cc5f37c762e4969ee2bcef236582f49a1d0c1389, for GNU/Linux 3.2.0, with debug_info, not stripped hello32-shared: ELF 32-bit LSB executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=355d690aa8d8a1d7c7cd59ad7733ceeed19772bd, for GNU/Linux 3.2.0, not stripped hello32-static: ELF 32-bit LSB executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=dff2032fad65fd9db3ba8b35b77312f00dab9704, for GNU/Linux 3.2.0, with debug_info, not stripped
FEDORA-2026-2577c8efe4 (gcc-16.1.1-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2577c8efe4
FEDORA-2026-2577c8efe4 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2577c8efe4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2577c8efe4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-2577c8efe4 (gcc-16.1.1-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
I can confirm 16.1.1-2 fixes the issue.