This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: deprecation


On Tuesday 22 May 2012 12:38:36 Roland McGrath wrote:
> > (What would the versions for the RPC symbols look like for an
> > architecture with GLIBC_2.14 or later as minimum version?  I suppose
> > that without --enable-obsolete-rpc the symbols would be present at the
> > minimum version, but not available for linking against.  Only if we
> > eliminate the need for the symbols to be used internally, maybe
> > arranging for libtirpc to be dlopened as needed once it has all the
> > required features, could we then set a later version as the one such
> > that if the minimum symbol version is that recent then the code isn't
> > built in at all.)
> 
> I was too lazy to bring this up earlier.  In theory, it's already a problem
> for x32, with minimum version 2.16.  But I'm adequately sure that everybody
> who builds an x32 distro is going to use --enable-obsolete-rpc for now that
> we can put off "doing it right" until 2.17 at least.  Once we're doing this
> correctly, it will really be a problem to keep --enable-obsolete-rpc around
> unless we figure out some new machinery.

since there is no alternative for some packages than --enable-obsolete-rpc, it 
isn't much of a choice.  libtirpc doesn't provide all the headers/symbols that 
glibc does and that some packages use.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]