Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Apr 1996 15:29:05 -0700 (PDT)
From:      Douglas Ambrisko <ambrisko@tcsi.com>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        ambrisko@tcsi.com, pst@shockwave.com, jdp@polstra.com, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-ports@freefall.freebsd.org, rgrimes@freebsd.org
Subject:   Re: cvs commit: ports/net/socks5 - Imported sources
Message-ID:  <199604242229.PAA28716@cozumel.tcs.com>
In-Reply-To: <199604242143.XAA28780@uriah.heep.sax.de> from "J Wunsch" at Apr 24, 96 11:43:47 pm

next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch writes:
| 
| As Douglas Ambrisko wrote:
| 
| > | What's up with libcompat?
| > 
| > The issue is that currently libcompat gets linked in with libsocks5_sh.so.
| > This means that libcompat gets pulled in whenever LD_PRELOAD is used with
| > libsocks5_sh.so.
| 
| Hmm, i'm not sure if i understand you correctly here.
| 
| Are you saying you've got a libcompat.so linked?  This must be a very
| obsolete version, libcompat is supposed to only exist as libcompat.a
| now.

Sorry I wasn't quiet specific enough in my extensions.

libsocks5_sh.so was built with libcompat.a (via ld) so now libsocks5_sh.so 
contains libcompat.a as part of libsocks5_sh.so.  So now when libsocks5_sh.so 
is pre-loaded via LD_PRELOAD via ld.so (what is does is first load and resolve
symbols in all LD_PRELOAD libs and then the builtin libs specificied in the
binarary at build time.  This is so socks can intercept libc's network
calls).  Clearly libcompat.a should not be linked with libsocks5_sh.so 
for FreeBSD because this forces every application to use the libcompat 
version of calls if LD_PRELOAD is set to libsocks5_sh.so, which is wrong. 

Now you ask why would Dave ever thing of linking a library with 
libsocks5_sh.so?  The reason would be for Kerberos support in libsocks5_sh.so.
Socks5 supports Kerberos 5 to encrypt all data communication that 
libsocks5_sh.so makes.  Since an application may not have been linked with
Kerberos, then libsocks5_sh.so could fail when making a Kerberos call.
So we need to link Kerberos into libsocks5_sh.so, to make sure Kerberos
symbols are resolved.  Now it may have been better if Dave did a dlopen
of the Kerberos lib, but he doesn't and I'm not sure why maybe he doesn't
want to depend on a shared lib version of it and would like it 
"statically" linked to libsocks5_sh.so.  He would also have to add code
to figure out when to dlopen it etc. 

| Despite of this, it should always be possible to avoid libcompat with
| only minimal effort.  All of the functions in libcompat are supposed
| to be obsolete -- that's why they are there (and do no longer bloat
| libc as you will find in many commercial systems).

Yep that's why we want to get rid of libcompat.  Strictly speaking Socks5
doesn't need but one of the clients "archie" that he includes in the
distribution does and I don't know how much hacking he wants to do to that
and I'm waiting for his reply.

I think this is all pretty neat stuff and was fun to get going.

Doug A.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604242229.PAA28716>