3.3 configure static
Erik Poupaert
erik.poupaert@skynet.be
Wed Jul 9 08:45:00 GMT 2003
> 3) Build your application with this toolchain, and verify it does not link
> to any DSO apart from libc, libm and libpthread.
> I haven't tried this, but I'd expect that because of 1) your binary will
> work with the libc.so installed on your build machine or any later
> version, and 2) will not depend on shared versions of libgcc_s and libgcj.
It's only a temporary problem. One day 3.3 will replace 3.2.x on most machines, and
the problem will be gone.
> Note this is not the same as simply building your application with
> -static. I strongly recommend against -static for distribution.
I've tried that one. Duh. Compiling with "-static" doesn't even work properly, for
example, with SWT, because Gtk2 must then be specially built with static support.
With "-static" the linker will try to link everything statically, including Gtk2
dependencies, while there is no need for that. The Gtk2 dependencies, such as
libm.so, libpango.so and so on, may be considered to be "system dlls", that one does
not need to distribute seperately. The idea is that one should be able to distribute
an executable, and that it should reasonably work on most Linux platforms with Gnome
installed. But then again, binary distribution is not my preferred distribution
method, especially not on Linux.
> I've grown tired of hearing that Windows somehow solves a problem that
> GNU/Linux does not. For another, what you might think are static executables on
> Windows certainly are not: run objdump -p on them sometime to see what DLLs they
> depend on.
It's just an issue of perception. The dlls the Windows executable depends on, are on
the machine anyway. That is why people could have the impression that there are no
dll dependencies. The truth is that there are no *additional* dll dependencies. I was
just wondering if it was not possible to create the same perception on Linux? If not,
no big deal. But then again, when 3.3 replaces 3.2.x on most machines, that
perception will be applicable to Linux too.
Another consideration is the fact that the need to target existing Linux systems is
quite small. Currently, you usually bring Linux with you. It's not that you usually
find it installed already. With Windows, things are a bit different, and you usually
have to deploy on the horrors of the past. So the need is less pressing anyway, for
Linux.
More information about the Java
mailing list