HEADS-UP: Planning on deprecating libc_r for 6.0

[Scott Long]

Giorgos Keramidas wrote:
> On 2005-04-13 08:43, Scott Long <scottl at samsco.org> wrote:
> 
>>Poul-Henning Kamp wrote:
>>
>>>>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.
> 
> 
> Exactly the reason why I like the idea of deprecation messages but also like
> being able to disable them.  It's not really impossible or unthought of that
> it may take a stupidly long amount of time for a vendor to fix their broken
> application that depends on a bug of a deprecated library *and* misbehaves
> because of a message sent to stderr by the linker.
> 
> Having said that, since this is being deprecated in 6.X, which is pretty much
> "current" and people aren't really expected to jump on the FreeBSD-current
> wagon if they use FreeBSD for production, how many people use libc_r now that
> may be bitten by the deprecation messages?
> 

Well, 6-CURRENT will turn to 6-STABLE in just a few months.  It's not
years in the future =-)

Scott