Date: Wed, 13 Apr 2005 10:39:36 -0600 From: Scott Long <scottl@samsco.org> To: Giorgos Keramidas <keramida@freebsd.org> Cc: David Xu <davidxu@freebsd.org> Subject: Re: HEADS-UP: Planning on deprecating libc_r for 6.0 Message-ID: <425D4B48.4070801@samsco.org> In-Reply-To: <20050413152707.GA41331@orion.daedalusnetworks.priv> References: <19268.1113403507@critter.freebsd.dk> <425D302C.1060006@samsco.org> <20050413152707.GA41331@orion.daedalusnetworks.priv>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > On 2005-04-13 08:43, Scott Long <scottl@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?425D4B48.4070801>