This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: versioning of _Unwind_*() symbols
On Tue, 2004-04-20 at 16:06, David Mosberger wrote:
> When built against libunwind, libgcc_s.so should have a dependency
> on libunwind.so and hence no symbols got lost.
The old versions of the functions were lost.
> However, there is still a versioning issue. AFAIK, the C++ ABI
> doesn't specify (allow?) versioned symbols. Certainly Intel's
> _Unwind_*() routines also are not versioned.
You seem to have glossed over the glibc comments here. glibc versions
symbols. If glibc can and does version symbols, then it seems to me
that libgcc also can and should version symbols. Do the ANSI or POSIX
standards say anything about symbol versioning? I doubt that they do.
Hence whether the C++ ABI says anything about versioning is irrelevant.
Versioning is a system issue. In order to provide compatibility from
one gcc/glibc version to the next, we version symbols. I see nothing
wrong with this.
As I mentioned before, the only problem here seems to be that we dropped
symbols from libgcc to save space. But this loses compatibility, which
is a bigger problem than saving space, so we should put the symbols
back. This won't break libunwind, as libunwind is linked in before
libgcc, so we still get the libunwind versions of the routines if
libunwind has them.
If a system vendor chooses to ship libunwind as a required part of a
linux distro, then and only then, can we drop the symbols from libgcc,
as then we no longer need them for compatibility with the system version
of libgcc_s.so. This assumes we don't need compatibility with previous
linux distro releases, and/or there is a separate libgcc_s.so for
compatibility with old linux distro releases.
Note that one way to get libunwind accepted as a standard part of a
linux distro is to add it to a package that is already a standard part
of a linux distro. This will be a lot of FSF paperwork though. libffi
is technically not part of gcc, and some people have been trying to fix
this for about 9 months with no apparent success so far.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com