On Wed, 24 Sep 2003, Dan Nelson wrote: > Does it really matter if you end up linked to multiple threads > libraries? The first library providing a symbol wins, so the other > shlibs just won't get used at all. Libraries linked from the executable > trump libraries linked from libraries, and LD_PRELOAD wins above all. > If one threads library exports a symbol not in the others, I'd call that > an API bug in the first library. > > This should be no different from explicitly linking in dmalloc to > override the malloc functions in libc, for example.
One potential downside to the LD_PRELOAD approach is that it will only work for applications that aren't setuid/setgid. While today most of our privileged and credential-munging applications aren't threaded, I'd like to avoid precluding that in the future as much as possible. What mechanism should be used when LD_PRELOAD is being ignored due to issetugid() returning true? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
