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] |
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] |