HEADS-UP: Planning on deprecating libc_r for 6.0

Giorgos Keramidas keramida at freebsd.org
Wed Apr 13 08:27:15 PDT 2005

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?

More information about the freebsd-arch mailing list