Bug 109388
Summary: | glibc in RH3 breaks some binaries. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Geoff Dolman <geoff.dolman> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 3.0 | CC: | bnagy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-11-07 13:04:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Geoff Dolman
2003-11-07 12:50:40 UTC
That means there is a bug in Veritas software, which means you should talk to them so that they get it fixed. In the mean time you can work around it, citing from Taroon RELEASE-NOTES: " Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed." As for the second question, have you installed openmotif21 package? Yep. openmotif-2.1.30-11 I also have this problem with java now :( Error occurred during initialization of VM Unable to load native library: /usr/openv/java/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference As far as I can make out specifying LD_PRELOAD=/lib/libc.so.6 (or any such change of LD_LIBRARY_PATH) does not fix this. However, I think I shall resolve this by reverting to my backup of 2.1 until a supported product comes out. That's certainly not what is included in Taroon, which should have: ls openmotif*.i386.rpm openmotif21-2.1.30-8.i386.rpm openmotif-2.2.2-16.i386.rpm openmotif-devel-2.2.2-16.i386.rpm openmotif21-2.1.30-8 includes libXm.so.2, while openmotif-2.2.2-16 includes libXm.so.3 As for Java, you surely aren't using the JDK included in the distribution. Older JDKs are very buggy and this is just one of the symptoms. You can work around it, e.g. with: gcc -O2 -shared -o ~/libcwait.so -fpic -xc - <<EOF #include <errno.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> pid_t __libc_wait (int *status) { int res; asm volatile ("pushl %%ebx\n\t" "movl %2, %%ebx\n\t" "movl %1, %%eax\n\t" "int \$0x80\n\t" "popl %%ebx" : "=a" (res) : "i" (__NR_wait4), "0" (WAIT_ANY), "c" (status), "d" (0), "S" (0)); return res; } EOF and using LD_ASSUME_KERNEL=2.4.19 LD_PRELOAD=~/libcwait.so when you need to load the buggy JDK. Or better just use the JDK which is included in the distro. How is it that Red Hat has no obligation to fix this problem??? One of the major features advertised by RH is that RHEL is a "Key Certification Platform": Red Hat actively works to certify leading industry ISVs and OEMs for comprehensive application and hardware support for Red Hat Enterprise Linux products. Here are just some of the vendors supporting Red Hat Enterprise Linux: blah blah VERITAS I'm having the problem with Java as well. It is not a java bug, it is a libc bug. Works well on WS2.x It is obviously the compat librairies that are broken. The code snippet above did fix the problem I posted but there were still others... After many, many hours of trying to get this to work I gave up, took my tape of AS2.1 and downgraded the machine. I am hoping that Veritas Netbackup 5.0 will be certified to run on AS3.0 because otherwise it's not really an option to upgrade. The disappointing thing about this is not that the problem can't be fixed in-situ but the fact that no one thought to find out whether Netbackup 4.5 worked (or would be supported by Veritas) on AS 3 before it was released. This is not some minor inconveniance. Anyone who has even quite mediocre storage requirements is going to need tape autoloaders unless they want to spend all day feeding tapes into single drives. Releasing an OS without a supported product from arguably /the/ major vendor of software that can do this job and without native tools in the OS is not what I would describe as 'comprehensive application support'. Thanks for the heads up. Actually, the JDKs from Sun, 1.3.1_10 and 1.4.2_03 both work on WS3.0 and are compatible with most jave apps. The IBM JDK that is bundled with WS3.0 seems buggy. So switching the Sun JDK solved that problem. But I agree, a lot of other software, written in C is still failing so WS2.1 is still the way to go in those cases. Thanks again, Balazs Use LD_ASSUME_KERNEL=2.2.5 instead, it solved the issue for me. The software was Veritas Nebackup 4.5 FP3. OS: Fedora Core 2 I made a bpjava-wrapper script: #!/bin/sh export LD_ASSUME_KERNEL=2.2.5 ${0}_org $* And I did the following: mv bpjava-msvc bpjava-msvc_org ln -s bpjava-wrapper bpjava-msvc Do the same with all files starting with "bp" in /usr/openv/netbackup/bin. Regards, Martin Correct, but a simplest way is to add env = LD_ASSUME_KERNEL=2.2.5 in the bpcd vnetd bpjava-msvc and vopied files in /etc/xinetd.d Regards, Cedric. |