Thanks to all, I had noticed the LD_ASSUME_KERNEL=2.2.5 line in the java start script and tried commenting it out. While it DID eliminate the specific error messages - allowing WAS to actually finish its startup, it fails to actually work. Nothing seemed to make WAS a happy camper. On another system, we also eliminated the error messages, but tomcat and iasp didn't work.
Finally, we found a new version of java (we were at 1.3.1, we are now at 1.4), and that fixed everything but WAS 4.0. I am not the Websphere person, but if I am getting my information right, Websphere 4.0 is not GA with a 2.4 kernel, so we are probably lucky it works at all even on 2.4.7. Anyway, thanks to all, we have most everything fixed, and as far as WAS goes, we can live with it at the old level until there is a properly certified, GA version. I do have a few more questions, which I will burden the forum with as soon as I can get enough coffee into my system and my mind realizes that it really is Monday and I really am back at work.... Thanks, Steve Arden > Return-Path: <[EMAIL PROTECTED]> > MIME-Version: 1.0 > X-MIMETrack: Serialize by Router on MAILOUT/IBA(Release 5.0.6a |January 17, 2001) at 31.10.2002 10:43:42, Serialize complete at 31.10.2002 10:43:42 > Content-Type: text/plain; charset="us-ascii" > Approved-By: [EMAIL PROTECTED] > Sender: Linux on 390 Port <[EMAIL PROTECTED]> > From: Sergey Korzhevsky <[EMAIL PROTECTED]> > Subject: Re: shared library problems > Comments: To: p43cibmgs-Arden <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Precedence: list > > When I tryed to install WAS 4.x on my SuSE 390x 2.4.17 kernel i had the > same problem (At least, i think so). I looked at wrapper for JAVA and > found that: > > #------------------------------------------------------------------------- > # The line "export LD_ASSUME_KERNEL=2.2.5" disables the use of floating > # stacks on RedHat distributions. Floating stacks can be enabled by > # commenting it out. Do not do this unless all of the following are true: > # > # 1) you are running linux/s390 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > # 2) your kernel version is 2.4 or higher > # 3) you have glibc version 2.2.1 or higher > # > # The commands > # uname -m > # uname -r > # rpm -qv glibc > # will return the relevant results. We recommend that you enable > # floating stacks if your system is suitable. > # > export LD_ASSUME_KERNEL=2.2.5 > > > > So, when i comment it out all was ok. > > > > > > > WBR, Sergey > > > > > p43cibmgs-Arden <[EMAIL PROTECTED]> > Sent by: Linux on 390 Port <[EMAIL PROTECTED]> > 30.10.2002 19:52 > Please respond to p43cibmgs-Arden > > > To: [EMAIL PROTECTED] > cc: > Subject: shared library problems > > > I don't recall seeing this go by in the forum, but there's no guarantee I > was > always paying attention. > > We are trying to move most of our Linux S390 systems from 2.4.7 to 2.4.17. > We > started with a Suse 7.2 as a base. The upgrades were done, with a lot of > help > from others on the forum, as recommended in developerworks. By that I mean > we > upgraded the kernel sources, > added the timer patch, > kerntypes, > the 31 bit qeth module, > binutils 2.12.90.0.14, > gcc 3.1.1, > glibc 2.2.5, > modutils 2.4.7, > s390-tools 1.1.3. > After fighting through that I was too bushed to bother with gdb. > > Now as we try to upgrade production systems, we are being hit by various > products that fail to run due to the following: > > "error while loading shared library: libc.so.6 : cannot open shared > object file: No such file or directory" > > The above message is an approximation, I let the exact messages get away > when > backing out of 2.4.17. > Anyway, /lib/libc.so.6 is a link to /lib/libc-2.2.5.so. > > We are getting this with WAS 4.0, Tomcat 4.0, IASP 2.0, .... > Interestingly, when tracing most of them, it turns out that they were all > running java when they failed, so maybe it's only java that's a problem. > > Dumping a trace here is a bit large, but after java does a fork/execve, it > successfully opens and reads from /lib/libc.so.6, closes it, and tries > /usr/lib/libc.so.6 which doesn't exist, although in desperation we copied > it > there just to see what would happen. It didn't help. Typically the execve > is for > /usr/bin/expr or /bin/ls, or something that works all time except when > done by > java. > Java is IBMJava2-SDK-13.s390. > > Anyone have any ideas??? > > > Steve Arden > > [EMAIL PROTECTED] > IBM-Global Services @ Lucent > (630)979-7124 Steve Arden [EMAIL PROTECTED] IBM-Global Services @ Lucent (630)979-7124
