Date: Wed, 13 Apr 2005 16:45:07 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> 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: <19268.1113403507@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 13 Apr 2005 17:42:00 %2B0300." <20050413144159.GA40749@orion.daedalusnetworks.priv>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19268.1113403507>