RFC: [Long] Change PTHREAD_LIBS to -pthread for -CURRENT

Doug Ambrisko ambrisko at ambrisko.com
Wed Jun 9 23:49:34 GMT 2004


Charles Swiger writes:
| Second, LD_PRELOAD is intended to solve the issue of "how do I 
| substitute a different version of a shared library (so long as it 
| provides the symbols needed by the program so that the executable 
| dynamicly links) than the one the program was actually linked against".
| 
| Solaris uses this mechanism to support different flavors of malloc 
| besides the default SCD-compliant one, such as bsdmalloc and mapmalloc, 
| and it also uses this mechanism to provide backwards compatibility with 
| buggy programs as per "man ld.so.1":
| 
| NOTES
|       The user compatibility library /usr/lib/0 at 0.so.1 provides  a
|       mechanism  that establishes a value of 0 at location 0. Some
|       applications exist that erroneously assume a null  character
|       pointer  should  be  treated the same as a pointer to a null
|       string. A segmentation violation will occur in these  appli-
|       cations  when  a null character pointer is accessed. If this
|       library is added to such an  application  at  runtime  using
|       LD_PRELOAD,  it  provides an environment that is sympathetic
|       to this errant behavior.  However,  the  user  compatibility
|       library is intended neither to enable the generation of such
|       applications, nor to  endorse  this  particular  programming
|       practice.
| 
| For this to actually be useful (usable?) under FreeBSD, the implication 
| is that the different thread libraries which exist under FreeBSD need 
| to be interchangable via dynamic linking, rather than requiring 
| compile-time changes to the code using threads.  I don't know whether 
| libpthreads, libc_r, and libkse can be switched using dynamic linking, 
| but if they can't, pick the best implementation and make it the default 
| that "cc -pthreads" uses.

As the original author of the FreeBSD implementation of LD_PRELOAD 
with help from the commiter that commited it for me ...

There is a problem with LD_PRELOAD since the libc's are not interchangable.
With Solaris you can do "runsocks" a thread program and it works but fails
under FreeBSD.  "runsocks" does a LD_PRELOAD of a stub libc type
thing that has a replacement network calls like send etc.  It then
dlopen libc to then run the real send etc. after the socksification
has been done to the protocol to talk to the socks proxy if needed.
Under FreeBSD we need to pull in the libc_r version instead of
libc if the program is threaded.  This is not a problem with Solaris
but is with FreeBSD.  I forget about Linux.  So to socksify Netscape
I had to compile a socks shim with libc_r and then use that version
if the program was threaded or you the other if it wasn't :-(

Adding  the minimal libc_r layer onto of libc didn't really make this 
situation better.

Now I admit I don't use this as much as a few years ago.  These problem
occured after the LD_PRELOAD was added since it was added before libc_r
existed.

FWIW,

Doug A.


More information about the freebsd-ports mailing list