Re: [patch] remove atoff

[Eric Blake <eblake at redhat dot com>]

On 08/26/2011 11:05 AM, Ralf Corsepius wrote:
> You may be able to compile such a package on "*some* versions of linux"
> and "some versions of cygwin" at present time, but ... not anywhere
> else, comprising "other Linuxes" and "Linux 5 years ahead" (When glibc
> will have changed the API or have abandoned such extensions).

You don't understand.  As long as Uli maintains glibc, then glibc will 
NEVER abandon any extension interface, no matter how archaic it is. 
glibc may remove an interface from the headers so that new apps won't 
use it, and it relies on ELF symbol versioning to export the symbol only 
to apps that were compiled against older library versions where the 
symbol was declared, but it CANNOT remove the entry point itself from 
the shared library.  And since the entry point itself must exist in the 
shared library, the code will still exist in the repository, for the 
benefit of compiling that versioned symbol, even if no modern program 
can use that symbol, all so that old programs will continue to run 
without recompilation regardless of a glibc upgrade.

The same holds true for cygwin, except that cygwin does not have the 
luxury of ELF symbol versioning.

Now, there are some other things to remember.

1. If you use static linking, then atoff() does not hurt you if you do 
not use it, because it is alone in its .o file.  You have ZERO code 
bloat for unused .o files in static linking - so who cares what 
extensions newlib was providing, as long as they were in separate .o 
files, then it won't affect the size of your statically-linked embedded 
program if you don't use it.

2. Conditional compilation on newlib is okay.  You are free to propose a 
configure switch or other macro that platforms can define according to 
what extensions they want - so cygwin can keep atoff for backwards 
compatibility while RTEMS compiles it out.  In fact, the ELIX levels 
sort of do that, although I'm not sure if ELIX levels adequately map to 
current levels of standards compliance.  Also, it might be an acceptable 
solution if you are willing to write a patch to move atoff().c out of 
newlib and into cygwin, so long as you prove that cygwin is the only 
shared library that cannot drop atoff(), and that the end result of the 
patch is that cygwin still provides the atoff() entry point no matter 
what newlib does.

3. If you use dynamic linking, you cannot change interfaces in a 
backward-incompatible manner without causing an uproar.  Because your 
library is shared, you cannot know which users linked against which 
interfaces, and even though MOST users won't be using stupid interfaces, 
you can't say for certain that ALL users avoided it.

--
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org