> I just want to make a static binary.
We have a bit of a problem here, I'm afraid. The term `static binary'
doesn't make sense on Solaris. You can have a particular library
linked in statically, but not all *.so objects are libraries, so you
can't have static binary.
> When I use "-static" all sorts
> of system libraries complain about functions that reside in
> libdl, even though I have not put "-ldl" on the link line.
They don't reside anywhere else.
> Seems kind of silly that Sun would tag static binaries as something
> _not_ to do if you want portability to future releases... I guess
> they change the syscalls all the time.
Depends on what you mean by that. Syscall numbers are the same. They
don't guarantee it, but in practice they are. They are even the same as
SunOS syscall numbers. Assembly programs which directly call kernel
will work, up to Solaris 2.6. Perverse things I was doing with SPARC
register windows on SUnOS won't, but most things will. Solaris 2.6
brought large file environment. File sizes and offsets become 64-bit
integers. There is no way for a static binary from Solaris 2.5 to
work with this, since kernel knows about 64-bit stuff only. Remapping
to 32 bits (if possible) is done in libc. If you brought Solaris 2.5
libc with you, your program won't work.
Blame it on Unix 98 standard. Sun did have a part in it, but it was
mostly database vendors who insisted on a nightmarish solutions. Default
system libraries are slow and inefficient, because of support for
things that are 10 years old and support for incorrectly written
software. (Like, say, programs which define _XOPEN_SOURCE and expect
that strdup() will be available :-) But, for efficiency freaks like me,
Sun provides a library or two with their compiler which would be linked
instead of normal libc functions. So I compiled and linked GTK 1.2.3 today
with my best optimization flags and libraries. It crashed because the
efficient malloc() provided by libfast.a doesn't have support for broken
software.
Unless you absolutely have to, don't link statically with system libraries.
Sun will take care of portability, as much as they can. Not because of
you, but because of Oracle. You'll never see things which happen when
GTK changes API, even if some API changes. There is a price to pay for
that, but you're not the one who has to buy a faster processor.
--
.-. .-. Life is a sexually transmitted disease.
(_ \ / _)
| dave@srce.hr
| dave@fly.cc.fer.hr