HEADS-UP: Planning on deprecating libc_r for 6.0

[Scott Long]

Poul-Henning Kamp wrote:
> In message <20050413144159.GA40749 at orion.daedalusnetworks.priv>, Giorgos Keramidas writes:
> 
>>On 2005-04-13 07:36, Scott Long <scottl at samsco.org> wrote:
>>
>>>All,
>>>
>>>Now that we've had working KSE for 2 years, I'm planning to declare that
>>>libc_r will be deprecated in 6.0 [...]
>>>
>>>One question that has come up is how to warn the user at runtime about
>>>this deprecation.  Should the dynamic linker print a message to stderr
>>>when it gets a request to load libc_r?  Should it go to the console
>>>and/or syslog instead?  Should there be a way to disable these messages
>>>so as not to break wrapper programs that might be confused by the
>>>output?  Should we even bother at all with runtime warnings?
>>
>>How about modifying the dynamic linker to print a warning to stderr,
>>much like mktemp(3), but let the user disable it by setting an
>>environment variable, like LD_WARN_LIBC_R_DISABLE or similar?
> 
> 
> The user can disable it by adding a line in libmap.conf so let us
> not invent more handles to tweak but point the user at the right
> one.
> 

Well, the worry is that there are legacy apps out there that rely on
features/bugs only found in libc_r, therefore the user can't just
switch.

Scott