Re: dlsym(RTLD_NEXT) alternative to syscall() for hard wrappers
On Tue, Oct 15, 2002, Jonathan Schilling wrote: [...] First, thanks for this brilliant idea. I'll to incorporate it into the mainline for release in Pth 1.5.0. Note that for this to work you have to use the dynamically linked Pth libpthread, so that the real definition can be found in a downstream library (usually libc). [...] The defined(__USLC__) || defined(__svr4__) test is to activate it for SCO UNIX systems; if this were to be incorporated in mainline Pth, this would have to be replaced with a macro test driven from the configure process, since the syscall() method needs to be retained as an option for systems that don't have dlsym(RTLD_NEXT) and for static links. Are you sure that libpthread itself has to be a shared library? Wouldn't it be also sufficient if Pth lives in libpthread.a but the application using libpthread.a is dynamically linked against libc? So, I think it would be sufficient if libc is dynamically linked, but Pth itself is still allowed to be statically included in the application, right? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
Re: dlsym(RTLD_NEXT) alternative to syscall() for hard wrappers
Date: Tue, 15 Oct 2002 20:43:48 +0200 From: Ralf S. Engelschall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: dlsym(RTLD_NEXT) alternative to syscall() for hard wrappers On Tue, Oct 15, 2002, Jonathan Schilling wrote: Note that for this to work you have to use the dynamically linked Pth libpthread, so that the real definition can be found in a downstream library (usually libc). [...] The defined(__USLC__) || defined(__svr4__) test is to activate it for SCO UNIX systems; if this were to be incorporated in mainline Pth, this would have to be replaced with a macro test driven from the configure process, since the syscall() method needs to be retained as an option for systems that don't have dlsym(RTLD_NEXT) and for static links. Are you sure that libpthread itself has to be a shared library? Wouldn't it be also sufficient if Pth lives in libpthread.a but the application using libpthread.a is dynamically linked against libc? So, I think it would be sufficient if libc is dynamically linked, but Pth itself is still allowed to be statically included in the application, right? Yes, you are right. Jonathan Schilling SCO/Caldera [EMAIL PROTECTED] __ GNU Portable Threads (Pth)http://www.gnu.org/software/pth/ User Support Mailing List[EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
