[roland/Versions.def] Get rid of Versions.def source file

On Fri, 21 Mar 2014, Roland McGrath wrote:

> > No, it worked previously - the point is that GLIBC_2.2.5 is only mentioned 
> > in Versions files (sysdeps/unix/bsd/Versions 
> > sysdeps/unix/sysv/linux/x86_64/Versions mach/Versions hurd/Versions) that 
> > aren't used for MIPS, but used in SHLIB_COMPAT in files that are used for 
> > MIPS.
> 
> Oh, I see.  Before Versions.def had the union of all sysdeps/.../Versions
> files in the source tree.  Now the generated file gets only the union of
> all Versions files actually selected in the current configuration.  Someone
> (like Carlos when reviewing my change ;->) should check what Versions.def
> items were lost in some configuration.  But I guess the ones that matter
> will come out in usual testing now with -Wundef.

As it turns out, adding the GLIBC_2.2.5 version (patch below) does not fix 
things; it removes the -Wundef warnings and is presumably correct on that 
basis, but doesn't get the symbols back at their correct GCC_3.0 version.

If I build for mips64el-linux-gnu (n32 ABI), at the commit before the 
Versions.def change, I get libc.map ending with

GLIBC_2.18 {
  global:
    __cxa_thread_atexit_impl;
} GLIBC_2.17;
GLIBC_2.19 {
  global:
    getrlimit64;
    setrlimit64;
} GLIBC_2.18;
GLIBC_PRIVATE {
  global:
[...]
} GLIBC_2.19;
GCC_3.0 {
  global:
    __deregister_frame_info_bases; __register_frame_info_bases;
    __register_frame_info_table_bases; _Unwind_Find_FDE;
};

At the following commit, plus the addition to elf/Versions, it ends:

GLIBC_2.18 {
  global:
    __cxa_thread_atexit_impl;
} GLIBC_2.17;
GLIBC_2.19 {
  global:
    getrlimit64;
    setrlimit64;
} GLIBC_2.18;
GLIBC_PRIVATE {
  global:
[...]
} GLIBC_2.19;

with no GCC_3.0 version, and the symbols that should be in such a version 
appearing in GLIBC_2.0 instead.  But for an i686 build (on a different 
system) I do see the GCC_3.0 version.  And I also see it for a powerpc32 
build on the same system as the mips64el-linux-gnu build, so it appears to 
be something about the configured host / set of symbols / symbol versions 
rather than a build environment issue.

2014-03-22  Joseph Myers  <joseph@codesourcery.com>

	* elf/Versions (libc) [EXPORT_UNWIND_FIND_FDE]: Add empty
	GLIBC_2.2.5 version.

On Sat, 22 Mar 2014, Joseph S. Myers wrote:

> with no GCC_3.0 version, and the symbols that should be in such a version 
> appearing in GLIBC_2.0 instead.  But for an i686 build (on a different 
> system) I do see the GCC_3.0 version.  And I also see it for a powerpc32 
> build on the same system as the mips64el-linux-gnu build, so it appears to 
> be something about the configured host / set of symbols / symbol versions 
> rather than a build environment issue.

Specifically, it's something to do with MIPS omitting versions between 
GLIBC_2.0 and GLIBC_2.2.  If you add sysdeps/i386/shlib-versions reading

i.86-.*-linux.*		libc=6			GLIBC_2.0 GLIBC_2.2

then you get the symbols wrongly moved from GCC_3.0 to GLIBC_2.0 on an 
i686-pc-linux-gnu build (I don't know if the build completes, but the 
broken libc.map is generated).

Sorry about that.  I'll try to start debugging this tomorrow (Tuesday,
US/Pacific).  But I might not find enough time to do it before next week.
If the mips breakage seems urgent, then it should be viable to revert my
change.

I'll start playing with the case you suggested for a modified i386 build
and hope that fixing that covers the real mips case.  I haven't found
easily installable mips cross tools for the system where I do most of my
libc debugging (based on Ubuntu 12.04.4).


Thanks,
Roland