libpci 3.8.0

[LinusDierheimer]

Hello everyone,

i really want to have a minimum libpci dependency of 3.8.0 (PCI_FILL_CLASS_EXT, PCI_FILL_DRIVER).

However, it was released 18.04.2022, and is therefore not available on every distribution (see here).

If an upgrade would be a no go for your setup, please let me know. I will leave this open for some time before upgrading, so people can see this.

[ceamac]

In Gentoo libpci is at 3.8.0 and already stable, so it's ok. libpci comes with sys-apps/pciutils

My only concern is if someone runs the already compiled binary on another distribution with a lower libpci. Can you detect this case during dlopen and handle it properly?

[luni3359]

I'm okay if this means the project can go forward. I wouldn't be able to compile it until the next lts release for my distro but I can wait until then.

[CarterLi]

Still have a lot of CentOS 7 servers to maintain

Can we have some #ifdef to keep the compatibility to the old version?

[LinusDierheimer]

Conclusion

To bring in more clarity, the affected features are:

• Better AMD GPU names, using amdgpu.ids (This is the important one)
• Driver detection

I have implemented it in the following way for a while now, and i think it is a good compromise, because nobody complained:

• If the version during compile time is less than 3.8, a self written code path is used, that does only work for the /sys pci interface. This means, that on some platforms some features are simply not supported, but i think we can live with that.
• If the version during compile time is 3.8 (or higher) the libpci and the self written code paths are both compiled. I think i managed to implement it in a way that the libpci codepath simply fails with < 3.8 and the self written one is used. This means that fastfetch compiled against libpci 3.8 should still work with lower versions, as long as the system is using the /sys interface.

Known systems that don't use the /sys interface:

• BSD
• Android