------- Comment #14 from joseph at codesourcery dot com 2008-06-30 19:30 ------- Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, ian at airs dot com wrote: > The three symbols __gttf2, __lttf2, and __netf2 are part of the standard > libgcc > interface at version GCC_3.0. The fact that they are not supported by all > instances of libgcc on all platforms seems to me to be irrelevant. When we > provide those symbols, we should provide them at version GCC_3.0. > > If we change the interface, then we should change the version. But if the > symbols are merely not present, then it is not necessary to change the > version. > The program will get an error either way. If we follow a different > procedure, > then we need to create different version scripts for each target. And that is > unlikely to work effectively. > > config/i386/libgcc-x86_64-glibc.ver and config/libgcc-glibc.ver are > problematic > because people fail to update them when libgcc-std.ver is updated. > > At least, that is how it seems to me. I don't know if this answers your > question, because I'm not sure what you are asking. The way it seems to me is that the practice so far has been that the versions do depend on the target - there are lots of target-specific version scripts, covering both target-specific symbols and the target-specific versions at which target-independent symbols were added. For example, the various GNU/Linux targets that underwent a transition in long double size have linker scripts to give appropriate versions to their TFmode symbols. This is in accord with the practice followed by glibc: if a symbol was accidentally not exported on a given target, it will be given the version number of the version in which it was finally exported on that target (see the handling of exp2l, for example). This means that the error tells you what version of libgcc is needed to get a particular symbol, and that the set of symbols in a version (for a given target) should not be changed once that GCC version is released. The special version scripts do not need to be updated when libgcc-std.ver is updated. They only need to be updated when the target to which they apply gains new symbols that are target-specific or that were added to libgcc-std.ver for other targets in an earlier version, which is rarer. On this basis, the issue is that we have a bug that some TFmode symbols were not put in GCC_4.3.0 on x86_64 although they were newly added there, and the question is whether we keep them in GCC_3.0 having released with them there, or move them to GCC_4.3.0 for consistency with the other TFmode symbols (breaking any x86_64 binaries built with 4.3.0 or 4.3.1 using __float128 and shared libgcc that use one of those symbols). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36669
