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 robert_at_fledge.watson.org Network Associates LaboratoriesReceived on Wed Sep 24 2003 - 08:11:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC