> I've had no problems building a static ethereal binary on my home
> Debian box, but have had some difficulties on Solaris ( although the
> Solaris envirionment I'm trying to build in is not an ideal environment ).
Well, in my Solaris environment - Solaris 2.6/SPARC, using GCC 2.95.1 -
it reported
ld: fatal: option -dn and -c are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
make: *** [ethereal_static] Error 1
"-dn" means "link statically".
"-c" isn't even documented, on the Solaris box on which I tried it.
However, the usage message for the Solaris 2.6 "ld" says:
[-c file] record configuration `file'
The options passed to "ld" appear to be constructed by the "collect2"
utility, which is part of GCC.
Note: Sun really really really really really doesn't like you to link
applications completely statically (this dates back to SunOS 4.0, at
least, but their dislike strengthened in SunOS 5.x); they'd really
prefer that you link dynamically with the system libraries.
Unfortunately, there's no standard way to specify, for example, that a
program is to be statically linked with GTK+ and GLib but dynamically
linked with libc.
On Digital UNIX 4.0F, using GCC 2.95.1, it reported
/usr/local/bin/ld:
-static is an obsolete undocumented option for linking kernels--perhaps
you meant -non_shared?
The ethereal_static binary is slightly larger than the ethereal binary:
{hostname}$ ls -l ethereal ethereal_static
-rwxr-xr-x 1 guy engr 3547136 Jul 12 00:09 ethereal
-rwxr-xr-x 1 guy engr 3604480 Jul 12 00:09 ethereal_static
However, the "file" command claims they're both dynamically linked.
On HP-UX 11.00, using GCC 2.8.1, it failed with
collect2: ld returned 1 exit status
/bin/ld: (Warning) Unsupported keyword -static to -static option - both
ignored
/bin/ld: Can't find library for -ldld
(In all cases, the non-static build of Ethereal succeeded.)
It did, however, succeed on FreeBSD 3.4 (with the 2.7.2-vintage GCC that
comes with it).
