HEADS-UP: Planning on deprecating libc_r for 6.0

[Poul-Henning Kamp]

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.