Date: Wed, 13 Apr 2005 13:08:24 -0500 From: Dan Nelson <dnelson@allantgroup.com> 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: <20050413180824.GE4842@dan.emsphone.com> In-Reply-To: <425D2041.7020501@samsco.org> References: <425D2041.7020501@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Apr 13), Scott Long said: > Now that we've had working KSE for 2 years, I'm planning to declare > that libc_r will be deprecated in 6.0 and removed by or before 7.0. > That means that libc_r will still be built and installed and usable > for 6.0 and likely for most of the 6.x lifetime, but its visibility > will decrease in favor of libpthread and possibly libthr. Given that > 7.0 is at least 2 years away, that should give plenty of time for > migration and testing. I assume that libc_r will also live on in > compatibility library archives long after that for those with legacy > apps. On a somewhat related note (libpthread/libthr feature parity with libc_r), is there any way to get truss to be kse/thr aware? Currently you can't trace kernel-threaded apps because the thread-switching syscalls get in the way. Compare the output of: truss host www.yahoo.com LD_LIBMAP=libpthread.so.1=libthr.so.1 truss host www.yahoo.com LD_LIBMAP=libpthread.so.1=libc_r.so.5 truss host www.yahoo.com The libc_r one is the only one with useable output. ports/sysutils/pstack (prints the stacks of a running process) is another handy tool that's libc_r only. Is libthread_db something that can help here and hide the differences between the libs? -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050413180824.GE4842>