Subject: static 'ls' for Solaris 2.5 for wu-ftpd 2.4

From: [email-masked] (Bill Heiser)
Date: Thu, 11 Apr 1996 17:59:13 -0400 (EDT)

Hi - in the wu-ftpd 2.4 docs, there is a discussion about
using a statically-linked version of "ls" in the bin directory
for anonymous ftp.  I am trying to do this for a Solaris 2.5
box.

I've tried building the 'ls' from the GNU "fileutils" package,
using static linking, but it's unable to link because that 'ls'
apparently needs a routine in "libdl".  The "libdl" man page
indicates the functionality contained therein is ONLY available
for DYNAMICally linked binaries.

Is there another version of "ls" which can be statically
linked for use on a Solaris 2.5 box?

Thanks in advance,
Bill

-- 
 Bill Heiser   [email-masked]

---

From: [email-masked]
Date: Mon, 15 Apr 96 09:40:35 0500

I gave up on this.  (I had the same results.)  Instead, I followed the
instructions in the original ftpd man page.  This describes the libraries
that should be copied into the ftp root so that ls and others can execute
after the chroot.  

Garry Williams
America Net, Inc.

>using a statically-linked version of "ls" in the bin directory for
>anonymous ftp.  I am trying to do this for a Solaris 2.5 box.

>I've tried building the 'ls' from the GNU "fileutils" package, using
>static linking, but it's unable to link because that 'ls' apparently
>needs a routine in "libdl".  The "libdl" man page indicates the
>functionality contained therein is ONLY available for DYNAMICally linked
>binaries.

---

From: Luc Desrosiers <[email-masked]>
Date: Mon, 15 Apr 1996 11:56:41 -0400

> that should be copied into the ftp root so that ls and others can execute

I remember seeing someone's page where he made available a static version
for solaris "ls". I can't find it anymore, but I'm sure it's still outhere.
On the other hand, I do have a static ls (from a modified gnu fileutils)
that works perfectly. The hack was done very fast and by no means optimized
for anything. For one thing, it parse directly /etc/passwd and /etc/group
without bothering about NIS. If you can live with that, I can give you
my "ls". If not, then I remember that all the other guy did to compile
ls staticly was to define stubs to missing libraries (make them return
nothing). By the way, my static ls is 304668 bytes big, much smaller
than a dynamic ls with all it's dependencies.

Luc Desrosiers
RISQ, CRIM 
-------

---

From: Dan Stromberg <[email-masked]>
Date: Mon, 15 Apr 1996 08:37:39 -0700

You can compile in stub functions for the dl* routines, to get a static
executable.  Sun won't support it, but it's worked in practice.
There've been flame wars over this, and lesser issues...

EG, for dlopen, compile in:

void *dlopen(const char *pathname, int mode)
{
}

...it's safe to do this, because the dl* functions don't _have_ to do
anything for static executables - the stuff that the dl* routines would
slurp in, is already present.  It's sufficient to just construct a stub
from the prototype in the manual page.

I feel that a minimal compiled-in "ls" would be a Good Thing - not
because it'd be slightly faster, but because it would simplify writing a
cross-platform installation script.  Minor apologies if this subject has
already been beaten to death.

---

From: Forrest Aldrich <[email-masked]>
Date: Wed, 17 Apr 1996 16:50:57 -0400 (EDT)

This has been a nasty problem... so, essentially, all I need to do is
to dig out all the dl* calls (with their proper args) and create stub
calls in an *.a archive and link the static execs with it instead?

This would be very useful for firewall-based applications.

If you have more details about how to do this, please let me know...

Thanks,

Forrie