Latest Vivante drivers require libstdc++ ABI 3.4.20

[drf]

Hello,

while integrating the new Vivante GPU driver release (5.0.11.p7.1), we found out binaries are now compiled against libstdc++ ABI 3.4.20 instead of the previous 3.4.15.

This situation is ridiculous to say the least. You are forcing people to use a toolchain which is AT LEAST GCC 4.9. Do you truly expect everyone to change their toolchain at this point in time? For example, we can't afford to change the toolchain on our platform, and now I seriously worry about you guys randomly releasing an update depending on GCC 5.0, which basically breaks every possible concept of Binary Compatibility.

I sincerely hope you can provide an updated build with the old libstdc++ constraints as soon as possible, as this currently holds back one of our product releases.

[Bio_TICFSL · Accepted solution]

This can be closed

[andre_silva]

Hi Dario,

I will check that, but so far on my side, I am using lbstdc++ even in yocto if I selected the softfp option.

regards,

Andre

[drf]

Any updates?

[andre_silva]

Hi Dario,

yes I was double checking the information I got.

All of our gpu  driver releases comes with upgraded toochain. Unfortunately there is not way to avoid it.

As additional information:

1. 3.14.28 1.0.0 GA release based on dizzy and it have 4.9.1 version.

1. 3.14.38  GA release based on fido and it have 4.9.2 version. Also may be libstdc++ upgrades as well.

When patch release for 3.10.53 1.1.1 / 3.14.28 1.0.1.x are planned, customers will get updated GPU drivers.

We can't have both ways stay on old toolchains which we did before and keep current on new toolchains.

Best Regards,

andre

[drf]

Hi Andre,

thanks for your reply. To be fairly honest, the argument you put forward is totally bogus. Unless you're relying on specific features of the updated toolchains (C++11? C++14?) there's literally no need for lifting the requirements on a higher version of the GCC toolchain. This is especially because if you compiled your drivers with an older toolchain, things would be fully functional on a newer toolchain due to how libstdc++ works in terms of ABI.

Whoever builds the driver (you or Vivante) needs to take this into account. Compiling drivers with reasonably old toolchains is a common practice (you can ask your competitor Texas Instruments/PowerVR, for example) and does not compromise in any possible way the runtime functionality on newer toolchains thanks to the multiple ABI support libstdc++ has. Forcing people to use a toolchain which was released originally slightly more than 1 year ago is pretty much against every concept of "enterprise" and "stable", and as much as I might understand a similar behavior from the Raspberry Pi and friends, I find this totally unacceptable when it comes to i.MX6, which is supposed to be an industry-ready platform with a different set of guarantees. It is the first time I ever witness something like that (yes, not even the RPi/Broadcom did such a thing, and they're around since a reasonable amount of time).

I hope you can voice this concern to whoever provides the binaries, especially because if the compatibility is ever broken again, we're talking about GCC 5.0 which breaks every possible concept of backwards compatibility, and it won't be a "straightforward" upgrade like 4.8->4.9. Again, any argument about the toolchain update/compatibility related to Yocto is totally wrong as every Linux developer should know. Just to give you a proof, we've been releasing to our customers countless releases of your drivers on top of a system built with GCC 4.8, without a single issue. The fact that you advise/support a specific version of Yocto in combination with your BSP does not mean you have to break every other configuration. Are your other Linux partners aware of this?

Please, stick to a specific toolchain for the whole lifetime of this platform, and consider supporting configurations different than "latest and greatest" in the future for your newer platforms.

If you need more details or anything, I'm at your disposal, or you can message me privately.

Thanks

[drf]

Hi Andre,

we just tried the softfp version with the same result. The output of our packaging system is as follows:

Requires: libEGL.so.1 libGAL.so libVSC.so libc.so.6 libc.so.6(GLIBC_2.4) libdl.so.2 libdl.so.2(GLIBC_2.4) libgcc_s.so.1 libgcc_s.so.1(GCC_3.5) libm.so.6 libm.so.6(GLIBC_2.4) libpthread.so.0 libpthread.so.0(GLIBC_2.4) librt.so.1 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(CXXABI_ARM_1.3.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.15) libstdc++.so.6(GLIBCXX_3.4.20) rtld(GNU_HASH)

For comparison, 3.10.53 was instead:

Requires: libEGL.so.1 libGAL.so libVSC.so libc.so.6 libc.so.6(GLIBC_2.4) libdl.so.2 libdl.so.2(GLIBC_2.4) libgcc_s.so.1 libgcc_s.so.1(GCC_3.5) libm.so.6 libm.so.6(GLIBC_2.4) libpthread.so.0 libpthread.so.0(GLIBC_2.4) librt.so.1 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(CXXABI_ARM_1.3.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.15) rtld(GNU_HASH)

Also, note that we are not using Yocto, for what matters. Can you please check the version of gcc and/or libstdc++ your 3.14.38 system is running on? If it's GCC < 4.9 then the dependency is purely bogus, but I would be quite surprised.

Thanks