[patch] remove atoff
Eric Blake
eblake@redhat.com
Sun Aug 28 01:18:00 GMT 2011
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
More information about the Newlib
mailing list