Bug 109388

Summary: glibc in RH3 breaks some binaries.
Product: Red Hat Enterprise Linux 3 Reporter: Geoff Dolman <geoff.dolman>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 3.0CC: bnagy
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-11-07 08:04:29 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Geoff Dolman 2003-11-07 07:50:40 EST
Description of problem: Veritas Netbackup 4.5 is broken by upgrading
from RHAS2.1 to RHAS3.0. The binaries when run report:

Incorrectly built binary which accesses errno or h_errno directly.
Needs to be fixed.

This is presumably similar to bug 90002 for RH9. Also another problem
(probably requiring another bug) is that RHAS3 does not provide
libXm.so.2 and a symbolic link to 3.0.1 does not work (at least not
with netbackup's xbp). This can be resolved by installing the version
of openmotif shipped with 2.1 rather than the one shipped with 3.0 but
this isn't ideal.

I appreciate that there is no obligation for Red Hat to support
Veritas products, but this is a total show-stopper as the tape library
on the machine is now a paper weight. I can't believe other people are
not facing this issue and it's a month or more before Netbackup 5.0 is

Version-Release number of selected component (if applicable):


which I installed from 


How reproducible: Always

Steps to Reproduce: 
1. Just try to run the binaries.
Actual results:

Incorrectly built binary which accesses errno or h_errno directly.
Needs to be fixed.

Expected results:

Additional info:
Comment 1 Jakub Jelinek 2003-11-07 08:04:29 EST
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?
Comment 2 Geoff Dolman 2003-11-07 10:48:34 EST


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.

Comment 3 Jakub Jelinek 2003-11-07 11:01:59 EST
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>
__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;

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.
Comment 4 Mark Leary 2003-12-22 13:07:56 EST
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:


Comment 5 Balazs Nagy 2004-01-08 20:25:44 EST
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.
Comment 6 Geoff Dolman 2004-01-09 04:45:42 EST
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
Comment 7 Balazs Nagy 2004-01-09 09:56:02 EST
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, 
Comment 8 Martin Stenderup 2004-05-28 07:25:44 EDT
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:
 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.

Comment 9 Cedric Buot de l'Epine 2004-08-04 04:14:24 EDT
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