Date: Wed, 23 Sep 1998 08:07:23 -0700 From: John Polstra <jdp@polstra.com> To: Warner Losh <imp@village.org> Cc: ports@FreeBSD.ORG Subject: Re: SOCKS port inspires question... Message-ID: <199809231507.IAA14603@austin.polstra.com> In-Reply-To: Your message of "Tue, 22 Sep 1998 22:56:38 MDT." <199809230456.WAA11754@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> First, how do I know tell at compile time what the object format for
> the port is?
I would use "#ifdef __ELF__". I haven't read the "one-liner" that
Bruce shot it down with. Maybe if I read it, it will stop working for
me, even though it works fine currently. :-)
> It seems to make a difference for symbol lookup in dlsym.
I'd recommend getting rid of the leading "_" unconditionally. The
a.out dynamic linker was fixed a long time (long enough) ago to do the
right thing if the leading underscore is missing. So getting rid of
it unconditionally will work for either object format.
> Second, socks seems to be unique in that it has a runsocks command.
> This command is unique, afaik, in that it sets LD_PRELOAD and
> runs the reset of the command line. This works great when you
> have just one binary format on your system, but buys the large
> agricultural land area when presented with an AOUT binary with
> a ELF library. Moving the AOUT library to the standard place
> (/usr/local/lib -> /usr/local/lib/aout) doesn't solve this problem
> because we set LD_PRELOAD to be libsocks5_sh.so and LD_LIBRARY_PATH
> to /usr/local/lib:${LD_LIBRARY_PATH}. The only way I see to fix it
> would be to do a file on the command, then try to jigger the path
> based on the file type. Thinking about this for a moment tells me
> this won't work on -stable or a aout system, so I'd also have to
> check the libsocks5_sh.so as well. Yuck!
Fix "runsocks" to use an absolute pathname in LD_PRELOAD, i.e.,
"LD_PRELOAD=/usr/local/lib/libsocks5_sh.so". This handles all the
cases that we purport to support, namely:
1. On a -2.2 system, everything is a.out and the libraries are in
/usr/local/lib.
2. On a -current system whose ports haven't been converted to ELF
yet, all ports are supposed to be a.out and the libraries are in
/usr/local/lib.
3. On a -current system whose ports _have_ been converted to ELF, we
don't support building new a.out ports. (We only support _using_
the old ones.) When you build the new port, it will be ELF and its
libraries will again be in /usr/lib.
Regarding the name of the library, when Satoshi said it should have
a version number I don't think he realized that it is like a shared
object that's explicitly loaded with dlopen(). I don't think it
should have a version number.
> So my second question is , should I bother with these relatively
> nasty edge cases?
My rule of thumb (speaking only for myself) is: support a.out well on
-2.2, and support ELF well on 3.0. Always bear in mind that a.out in
the 3.0 branch is _history_. We are not going to be a dual-format
OS after this transition period. People who think they can use 3.0
without switching to ELF are going to discover that they're wrong. If
it's really hard to support a.out on a 3.0 system, I wouldn't lose
any sleep over it.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809231507.IAA14603>