I have followed instructions to get the jdk for sparc, 1.3 loaded on this sparc workstation machine. I used a tar file and everything seemed to go fine. The usr/j2se directory was created with all the subdirectories and java files. However, attempting to run Java commands fails with a file not found error. It is not a path issue as I created a symbolic link and it does start to open up java. I will try to post the exact message on a follow up. Do I need to load some of the many patches I read about to get this to work? I have not loaded any as I thought it should at least run without the bug fixes. Any help will be most appreciated.
In our JDK distros, there is an environmental variable which has a Java class path to help the JVM find the classes. The installation instructions normally have a step to set these environmental variables. (I put them in /etc/profile)
Thankyou, however we have those set correctly I believe. The java engine actually is starting to launch and then it fails. I have seen it with the path not known and the error is simple not found. Being on 2.6 I think the application of required patches may be the key as some of those patches seem to address library files and other things mentioned in our error. Does this make sense?
Did you compile the Java binaries for static or dynamic libs? Sometimes problems with dynamic lib paths will cause the binary to fail after execution. Did you install the libs and update the dynamic linker configuration file (if using dynamic libs)? Or do you have statically linked binary?
>Did you compile the Java binaries for static or dynamic >libs? Sometimes problems with dynamic lib paths will cause >the binary to fail after execution. Did you install the >libs and update the dynamic linker configuration file (if >using dynamic libs)? Or do you have statically linked >binary?
I did not compile the Java binaries unless the unpacking of the tar file did that for me. I followed directions I got from sun and for Java 2 SDK Installation for Solaris.
They said in part....
On Sparc:
zcat j2sdk-1_3_0-solsparc.tar.Z | tart -xf -
I got 4 packages, became root and installed the packages
pkgadd -d . SUNWjrt etc......
I then had a usr/j2se directory fully loaded and it looked fine. I did not do anything else other then set the symbolic link which had pointed to usr/java1.1 to my new directory, trying bin and then jre with the same results both times. So I dont know how to answer your question.
I did not to anything with the location of libjvm location. There was a note in the instructions about the path within the SDK to the HotSpot Client VM:
jre/lib/sparc/client/libjvm.so
The path to the HotSpot Server VM:
jre/lib/sparc/server/libjvm.so
I did not know what to do with these being a newbie here. So does any of this ring a bell for you? Thanks.
Yes, you have dynamic loadable binaries with the pre-compiled distro. This means that your shell must know where to find the java dynamic libs. This can be done with an environmental variable (sometimes) like LDCONFIG (if your system has or uses this) or adding the path to a similar configuration file (if your system uses that 
)
Which environmental vars are used/installed for this application ? You can find them (on most OS)by typing the <B>env</B> command. Also, find out how your system handles dynamic loadable libs.
Thanks. so it is not the lack of patches!?
I have run env but will look further based on your comments.
Here is the exact error we get by the way:
Error: failed /usr/j2se/jre/lib/sparc/client/libjvm.so, because ld.so.1: /bin/../java/bin/../bin/sparc/native_threads/java: fatal: libCrun.so.1: open failed: No such file or directory
Yes, as you can see from the error message, the problem is that the binary cannot find the required dynamic lib when the binary is executed, which is a problem based on the dynamic loader (linker) and not something a patch fixes.
One quick way to fix this is to copy the libs to a standard ld path, like /usr/lib or /usr/local/lib (you might have to run a command like ldconfig or whatever for Solaris to insure the ld cache is updated). However, normally, there is an environmental variable for this (and this is my preferred approach). If you don't use env vars, then the ld config file is preferred. (this is all a matter of personal choice, however, and some folks just copy the files to /usr/local/lib or some place like that....)
I would like to use an enviornment variable, however I do not know which one to use. we have a LD_LIBRARY_PATH which equals a ton of directories associated with another application on this machine. We also had a JAVA_PATH which I do not see any more. The symbolic link,?? can that be changed to point to the libraries. It now points to /usr/java/jre? What am I exactly suppose to point to. Is it /usr/j2se/jre/lib or one of the directories I wrote out in my long reply above? There is also a /usr/j2se/lib directory so I am very confused as to what variable to use and what lib directory cannot be found. Thanks again.
LD_LIBRARY_PATH is a good environmental variable for adding directories to the LD (dynamic loader) search path. This path is not for Java classes, but for the libs (lib*.so and lib*.a files). There is a different environmental variable for the search path for Java classes.
Sorry this is still dragging on. I added to LD_LIBRARY_PATH /usr/j2se/jre/lib/sparc/client:/usr/j2se/jre/lib/sparc/server:/usr/j2se/lib/sparc:/usr/j2se/lib:/usr/j2se:
It didnt work (Do i need to reboot?) I then added this stuff to the PATH variable as well, same result. I keep getting;
Error: failed /usr/j2se/jre/lib/sparc/client/libjvm.so, because ld.so.1: /bin/../java/bin/../bin/sparc/native_threads/java: fatal: libCrun.so.1: open failed: No such file or directory
I cant find this libCrun.so.1 myself? Any further ideas? What is that file? Thank you so much for your valuable input so far.
Jim
I cannot find the file libCrun.so.1 but I did find it was included in Patch 105591-09. All attempts to add this patch seemed to fail. At first I was warned that patchadd was being used isntead of installpatch as the instructions stated. Then I seemed to get it to install by using pkgadd -d <dir>/<patch-id>/pkg SUNMlibC.
Hoever, the file is still not there. Isn't it possible i am missing this file in the /user/lib directory and how do I get it? This is becomming much more difficult then i could have imagined. Thank You
You have to search your filesystem for the file, libCrun.so.1 using some version of the find command (as you like) find / | grep libCrun.so.
Sometimes there has been a new version, i.e. libCrun.so.14 installed and you have to fix the symbolic link etc. For example, if a binary is built to load libCrun.so.1 and there is a patch or upgrade to libCrun.so and the current version is libCrun.so.19, you must create a symbolic link as required.
[Edited by Neo on 01-26-2001 at 12:59 AM]
The jdk is the latest from sun and it seems to be looking for libCrun.so.1 so i believe that is the latest version of that file. I will try to find the file on the machine but I do not understand how I can load a patch that specifically states it has that file included in it and then I cant find the file. What is the best way to do a full machine search for a file as i am still very new to this system. thanks again.
I would execute this command:
find / | grep -i libCrun
and search the entire file system for every occurance of the libCrun token. If you run the command above and you don't find it, then it has not been installed. You might find libCrun.so.14 or libCrun.so.2 (just making up names of files) etc.
You can also do something like:
find / | grep -i libCrun > /tmp/foo
and post the results (the contents of /tmp/foo) here.
I ran the command. It only finds the file in the directory where I placed the patch before loading it. I do not know why the patch did not place that fiel properly, do you know why that might happen? Also, should I just move the files from the /lib directory in the patch itself to my systems /lib directory?
Here is the output from the command:
you will note that patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
is where I put the patch.
# find / | grep -i libCrun
/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/net/localhost/opt/home/peri/patches/105591-09/SUNWlibC/reloc/usr/lib/libCrun.so.1
OK, now you found it (many times, what's up with that circular link problem?, BTW)
Copy libCrun.so.1 to /usr/local/lib or /usr/lib. Make sure you cache your ldconfig and this small step of your epic journey is done
Also, suggest you track down and fix that misconfigured (symbolic) link that is causing the circular listing pattern above.
[Edited by Neo on 01-26-2001 at 12:37 PM]
Ok, I did move those but I also found other errors asking for other files which led to other patches. I installed all these patches and Java came up fine!!!! SO, as a newbie, I am pretty proud of the fact that I first said it was patches missing from my machine. You seemed to say no, so I wasn't all wet! Anyway, my forte4j IDE is trying to come up but stops short referencing another file, I wiull work that out or post a new question. Can you recommend a solid book for a beginner so I won't have long episodes like this anymore?
AND
How do you get rid of the circular links you noted?
THANK YOU VERY MUCH NEO, YOU ARE A GREAT HELP.
To me, patches are something that are applied to source code and recompiled to correct errors. Adding dynamic libs etc. may be called 'patches' by the vendors, but they are not really patches, per se. In all technologies, the use of terms and changing uses of terms are always a core source of confusion.
So, because a vendor provides dynamic libs in 'patch format' does not make them 'patches'. In many systems, they are simply 'the libraries', etc. Installing libs are not patching source code and recompiling; so as a newbie, you need to be aware of that. All you did was install dynamic libs (reuseable binary modules)and these libs may or maynot be used for other distributions besides your Java JDK install.
BTW, if installing reuseable code modules (libs) were patches, then the entire concept of object oriented programming would then be called 'patchwork'!!
On your circular links, you need to look at the filesystem and study the links that have been created to trace down the problem. I suggest you look at the books recommended in threads in this forum (do a search) and get a good book on shell programming. It is time to close this particular thread, IMHO. Great job getting your JDK up and running.
BTW: If you can't get your circular links problem solved, please feel free to start a new thread on that particular problem/issue.
Perhaps others (in the future) with similar lib problems will find this thread helpful also.
[Edited by Neo on 01-26-2001 at 06:49 PM]