Name: krT82822 Date: 12/30/99


(see also 4031603, 4052974, 4062952, 4122684, 4288424)

The version and OS fields in http://java.sun.com/cgi-bin/bugreport.cgi aren't
flexible enough, so I'll say here:

This bug occurs on all Solaris 2.x versions, with both the reference
JVM (including 1.1.8, 1.2.2 and 1.3beta) and the production JVM
(including 1.1.8_09a and 1.2.1_04), with both native threads and
(for the reference JVM) with green threads. It probably occurs
on x86 Solaris, but I only have SPARC Solaris handy.

The "java application launcher" (...../bin/sparc/*_threads/java) has a
shared-library dependency on libX11.so.4. This means that, even if you're
running pure server code with no GUI, 'java' will refuse to run if the
X11 libraries aren't installed. For better or worse, we have server and
firewall machines where, as a matter of policy, the X11 libraries are
not installed. One developer here, writing a protocol bridge that would
normally be an ideal Java application, ended up doing the following:

    I decided I was not going to install X11 on my gateway machine just to get
    a command line elvin bridge - bloody java!. So, here is tonights hack.
    A self contained shell script which does a bi-directional e4-e4 link.
    yes, it uses 6 processes, but thats still less resources than java.

What's really sad about this is that the dependency on libX11 seems to be
completely unnecessary:

      - "/usr/ccs/bin/nm -D java" shows no X11-related symbols
(nor should it),

      - if I substitute a dummy libX11.so.4 that is an empty shared
library, 'java' runs the application just fine.

There is a similar bug report, 4031603 ("java and libjava.so are linked
against libX11.so.4"), that is marked closed and fixed, but that doesn't
seem to be true. If I had to guess, maybe it was true for some JDK 1.1.x
versions, but then perhaps someone added it right back again in response
to bugs such as 4062952, rather than fixing the real problem.

I would have guessed that this would be an issue for J2EE, where most or
all of the code running is non-GUI code, and administrators would want to
lock down the server machine as tightly as possible (e.g. no X11 libraries).
No?

-------------------

12/30/99 eval1127@eng -- tried with 1.2.2.x and 1.3 reference versions on Solaris 2.7. Unlinked libX11.so altogether, and verified user's claim

% cat Blah.java
public class Blah {
        public static void main(String[] args) {
                System.out.println("I can run WITHOUT X11 libs!");
        }
}

% java Blah
ld.so.1: /usr/local/java/jdk1.2.2/solaris/bin/../bin/sparc/green_threads/java: fatal: libX11.so.4: open failed: No such file or directory
Killed

% java Blah
ld.so.1: /usr/local/java/jdk1.2.2-001/solaris/bin/../bin/sparc/green_threads/java: fatal: libX11.so.4: open failed: No such file or directory
Killed

% java Blah (1.3.0 build "R")
ld.so.1: /usr/local/java/jdk1.3/solaris/bin/../bin/sparc/native_threads/java: fatal: libX11.so.4: open failed: No such file or directory
Killed

------------------

# pwd
/usr/openwin/lib

# ls -lat | grep libX11
-rw-r--r-- 1 root other 627 Dec 30 08:34 README_restore_libX11_LINKS
-rwxr-xr-x 1 root bin 758352 Sep 4 1998 libX11.so.4_SAVED

# cat README_restore_libX11_LINKS
root[sh]@fireant# ls -lat | grep libX11
lrwxrwxrwx 1 root root 13 Apr 15 1999 libX.so -> ./libX11.so.4
lrwxrwxrwx 1 root root 13 Apr 15 1999 libX.so.4 -> ./libX11.so.4
lrwxrwxrwx 1 root root 13 Apr 15 1999 libX11.so -> ./libX11.so.4
-rwxr-xr-x 1 root bin 758352 Sep 4 1998 libX11.so.4
-rwxr-xr-x 1 root bin 758352 Sep 4 1998 libX11.so.4_SAVED





(Review ID: 99435)
======================================================================