HEADS-UP: Planning on deprecating libc_r for 6.0
scottl at samsco.org
Wed Apr 13 09:43:28 PDT 2005
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
> 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 =-)
More information about the freebsd-arch