Date: Wed, 13 Apr 2005 08:43:56 -0600 From: Scott Long <scottl@samsco.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: David Xu <davidxu@freebsd.org> Subject: Re: HEADS-UP: Planning on deprecating libc_r for 6.0 Message-ID: <425D302C.1060006@samsco.org> In-Reply-To: <19268.1113403507@critter.freebsd.dk> References: <19268.1113403507@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <20050413144159.GA40749@orion.daedalusnetworks.priv>, Giorgos Keramidas writes: > >>On 2005-04-13 07:36, Scott Long <scottl@samsco.org> wrote: >> >>>All, >>> >>>Now that we've had working KSE for 2 years, I'm planning to declare that >>>libc_r will be deprecated in 6.0 [...] >>> >>>One question that has come up is how to warn the user at runtime about >>>this deprecation. Should the dynamic linker print a message to stderr >>>when it gets a request to load libc_r? Should it go to the console >>>and/or syslog instead? Should there be a way to disable these messages >>>so as not to break wrapper programs that might be confused by the >>>output? Should we even bother at all with runtime warnings? >> >>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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?425D302C.1060006>