Re: libposix versioning

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Mon, Jan 10, 2011 at 09:30:17PM CET:
>   2) We might remove some workarounds from gnulib, thinking that don't
>      affect recent systems any more. (We sometimes do this for Cygwin,
>      on the premise that Cygwin users update at least once every 2 years.)
> 
> In both situations, the older installation will provide a workaround
> for foo(), defining rpl_foo, and the newer installation won't.
> 
> How do you intend to solve this problem?
> 
>   a) Always assign a new major version number to a new build of libposix.

That would be a shame, having lots of version compatibility skew for a
library whose very reason of existence is to provide an interface which
for the most part has been stabilized years ago.

>   b) Add an rpl_foo symbol that merely redirects to the system's foo function
>      if there is a chance for situation 1 or 2 to happen.

Sounds like a good workaround to me.

Well, on ELF systems you could do all kinds of other things like, not
define rpl_foo in the first place and use RTLD_NEXT to find the original
instance of foo; ok, that's a bit overkill for most uses.  On Solaris
and glibc systems you could use symbol versioning.  Neither generalizes
easily to other systems though.

Thank you for taking API stability seriously!

Cheers,
Ralf