GCC compiler mismatch in F39 upgrade

,

My upgrade from Fedora 38 to 39 was smooth. The only thing is that when I tried to install linux-gpib-4.3.6 it complained that the compiler used to build the kernel was different from the gcc that came with the installation. The Fedora upgrade using “cat /proc/version” shows that it was compiled with (gcc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3) and “gcc -v” shows gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC). Note the mismatch between 13.2.1-3 for the kernel and 13.2.1-4 for the gcc compiler. I had to revert the gcc compiler to 13.2.1-3 and run ‘make clean’ to fix it. Otherwise I got the “modprobe: ERROR: could not insert ‘agilent_82350b’: Exec format error” when I tried to run “sudo modprobe agilent_82350b”. I’m new to this and assumed that the compiler versions should match with the upgrade done using “Upgrading Fedora Using DNF System Plugin” from fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline. Is this normal?

I cannot find that package in the fedora repos. Where did you retrieve it from?
Is it possibly a typo in the package name?

I did find references to it for debian, ubuntu, and raspios but nowhere was I able to find an rpm version.

I did find this GitHub - vddvss/linux-gpib-packaging: RPM specfiles and patches to install linux-gpib on Fedora related to the 82350B board and it specifically requires firmware before the driver may be loaded.

When installing software that is outside the fedora tree it is often upon the user to carefully read the documentation and follow instructions in the hope that the new software will work properly.
Only when the software is provided within the fedora repos or locally compiled can one be assured the proper compiler and kernel libraries will match. It is certainly unrealistic to expect 3rd party software will match the fedora 39 kernel and packages when it is only 2 days after final release of 39.

You also had a typo in the link provided. It should have been ‘docs.fedoraproject.org

NVIDIA’s kernel module apparently has a similar requirement that is overridden by RPM Fusion, but I don’t know if it’s this strict.

Your kernel was built during the final freeze, while a gcc update was also waiting for the freeze to end. The next kernel update will use this gcc version, but the next gcc update will make it mismatch again, and so on.

Thank you - I didn’t realize that the gcc versions could be different than the kernel build version. I will pay much closer attention to that for sure! BTW the “Linux GPIB Support” project is hosted on Linux GPIB Support download | SourceForge.net and has been a valuable resource since it started in 2001. I was following the included ‘Install’ instructions when I ran into the ‘Exec format error’ problem and as a novice Fedora user it took me a few days to figure out why.

Hi Bob,
You could try my repo on Copr to install RPMs for the linux GPIB driver.
I’m using DKMS (Dynamic Kernel Module Support) which will mean that the driver updates with the Kernel.

Michael

1 Like

Thanks Michael - If I have already installed it from the https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/ do I have to do a ’ ‘make clean’ and reinstall from Copr ? I would really like a DKMS version.

Yes, you should uninstall the autotools version. (keep a copy of /etc/gpib.conf if you’ve customized it)
The package that I made (derivative work of others!) is a lot more convenient in that it automates not only the rebuilding of the kernel module but also the loading of the firmware onto the Agilent/Keysight USB GPIB dongle (using systemd) … see GitHub - VK2BEA/linux-gpib files.
It appears that “vssvdd” (the other GPIB Copr repo) has not updated his package in many years (and there is no build for current Fedora versions).
This is why I decided to “pick up the torch” for Fedora GPIB users!
The version that is currently available is from the latest SVN trunk (as of Friday).
Let me know if you have any problems…

Michael

I uninstalled the autotools version and installed the RPMs for the linux GPIB driver from COPR several days ago.
Everything was working fine including your 8753 program until today when I used dnfdragora to update.
Now there are no GPIB files/folders in /dev or /etc and modprobe agilent_82350b throws an error.

I don’t understand enough about dkms to know if the version mismatch would prevent it from working properly, but I thought it might. So I ran a version check between the new kernel and gcc that were in the update and got this:

gcc -v gives: (Red Hat 13.2.1-6)
cat /proc/version gives: (Red Hat 13.2.1-4)

Great news, that you got it going.

Try doing …
$ sudo dnf reinstall dkms-linux-gpib
or / and
$ sudo dkms build --force linux-gpib/4.3.6-8.20231125svnr2069.fc39

I’ve found I needed to do this occasionally on some kernel upgrades. I haven’t found what is amiss but there is some issue.

I just did an update to 6.6.4, which is testing, and the update rebuilt the module OK (without having to reinstall dkms-linux-gpib)
If you look at the directory like that below (adjust for your kernel) you should see the kernel modules.

[maxwell ~] 😼 ls -l /var/lib/dkms/linux-gpib/kernel-6.6.4-200.fc39.x86_64-x86_64/module
total 184
-rw-r--r--. 1 root root  9068 Dec  8 22:43 agilent_82350b.ko.xz
-rw-r--r--. 1 root root 14208 Dec  8 22:43 agilent_82357a.ko.xz
-rw-r--r--. 1 root root  9952 Dec  8 22:43 cb7210.ko.xz
-rw-r--r--. 1 root root  4748 Dec  8 22:43 cec_gpib.ko.xz
-rw-r--r--. 1 root root 21232 Dec  8 22:43 gpib_common.ko.xz
-rw-r--r--. 1 root root  4548 Dec  8 22:43 hp82335.ko.xz
-rw-r--r--. 1 root root  9000 Dec  8 22:43 hp_82341.ko.xz
-rw-r--r--. 1 root root  8616 Dec  8 22:43 ines_gpib.ko.xz
-rw-r--r--. 1 root root 19412 Dec  8 22:43 lpvo_usb_gpib.ko.xz
-rw-r--r--. 1 root root  9744 Dec  8 22:43 nec7210.ko.xz
-rw-r--r--. 1 root root 20300 Dec  8 22:43 ni_usb_gpib.ko.xz
-rw-r--r--. 1 root root  9612 Dec  8 22:43 tms9914.ko.xz
-rw-r--r--. 1 root root 14952 Dec  8 22:43 tnt4882.ko.xz

The dkms module build log file is in …
/var/lib/dkms/linux-gpib/kernel-6.6.4-200.fc39.x86_64-x86_64/log/make.log

I see messages like …
Skipping BTF generation for /var/lib/dkms/linux-gpib/4.3.6-8.20231125svnr2069.fc39/build/drivers/gpib/agilent_82350b/agilent_82350b.ko due to unavailability of vmlinux
but this just relates to debugging metadata that does not effect operation.

Michael

Thank you Michael. I ran the $ sudo dnf reinstall dkms-linux-gpib and it created the new kernel DIR as you posted with the proper files. The previous one was there as 6.6.2…
Everything is working fine again after a reboot. I’ll see if the next kernel update works without having to reinstall dkms-linux-gpib and post back here.
Good work!

1 Like

dkms-linux-gpib does not appear in the fedora repo so it seems likely that it may not be updated with kernel updates. Some packages compiled with dkms are automatically updated, but only if they are installed properly. I find references to that at sourceforge so it must be 3rd party installed and compiled.

The whole purpose of dkms (Dynamic Kernel Module Support) is that the kernel module (not distributed with normal kernel tree) is rebuilt and installed when the a new kernel is installed.

I might have found the cause of the problem caused by kernel updates.
I was using a process in the RPM .spec file scriptlets (%pre and %preun) as used in the negativo package of the Nvidia driver. This seems to be flawed and I’ve changed it to scheme used by the zfs package.
There may have been symbolically linked directories that were left dangling when old kernels were removed, and this may have prevented the dkms system from installing the new version correctly.

So are you using Guile for scheme language?

Ha …
… I missed the definite article… “the scheme”

FYI - updated Ferdora 39 using dnfdragora update with kernel 6.6.6 and dkms worked fine.
/var/lib/dkms/linux-gpib/kernel-6.6.6-200.fc39.x86_64-x86_64/ was created automatically and gpib working.