3.3 configure static

Wed Jul 9 17:31:00 GMT 2003

> We do this all the time. The only problem I can think of is that a
> really old glibc may not be suitable.

I've now tested (on my own machine) with a dummy user "deploy", with a directory
"lib" in his home folder that contains:
deploy@linuxpresario lib $ ls -l
total 39692
lrwxrwxrwx 1 deploy users 13 Jul 9 19:04 libgcc_s.so -> libgcc_s. so.1
-rw-r--r-- 1 deploy users 913302 Jul 9 19:00 libgcc_s.so.1
lrwxrwxrwx 1 deploy users 11 Jul 9 19:02 libgcj.so -> libgcj.so.4
lrwxrwxrwx 1 deploy users 15 Jul 9 19:02 libgcj.so.4 -> libgcj.so
.4.0.0
-rwxr-xr-x 1 deploy users 39833506 Jul 9 19:00 libgcj.so.4.0.0
His .bash_profile contains:
deploy@linuxpresario deploy $ cat .bash_profile
...
export LD_LIBRARY_PATH=$HOME/lib:$LD_LIBRARY_PATH
And the executable carefully links into this "lib" directory first:
deploy@linuxpresario bin $ ldd showtimes
 libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4c827000)
 libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x4ca7c000)
 libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x4caea000)
 libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4c66e000)
 libm.so.6 => /lib/libm.so.6 (0x4c0de000)
 libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4c7dc000)
 libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4c812000)
 libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x4c7a7000)
 libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x4c456000)
 libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x4c4e6000)
 libdl.so.2 => /lib/libdl.so.2 (0x4c0d9000)
 libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x4c3e0000)
 libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x4c683000)
 libpthread.so.0 => /lib/libpthread.so.0 (0x4c218000)
 libgcc_s.so.1 => /home/deploy/lib/libgcc_s.so.1 (0x40011000)
 libgcj.so.4 => /home/deploy/lib/libgcj.so.4 (0x40019000)
 libc.so.6 => /lib/libc.so.6 (0x4bfa6000)
 libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x4c821000)
 libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4c1e4000)
 libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x4c568000)
 libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x4c55e000)
 libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4c534000)
 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4c103000)
 libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4c48d000)
 libz.so.1 => /usr/lib/libz.so.1 (0x4c26b000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4bf90000)
 libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4c50c000)
Now, for this user, and on my machine, it seems to work. There are no dependencies on
/usr/local/gcj/3.3/lib any longer. So I think I can consider such deployment to a
"lib" folder feasible on most linux systems, that are sufficiently recent (how
recent?), unless I've forgotten something?
Are there any dependencies in the ldd list that I shouldn't expect to be present on
the average linux system, with Gnome and Gtk2 present already?