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