Bug 122682

Summary: abort on dlclose() of shared libraries that have objects build in C++ in them
Product: Red Hat Enterprise Linux 3 Reporter: sheryl sage <sheryl.sage>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: domingo_cardenas, gnuss, laroche, shedberg
Target Milestone: ---   
Target Release: ---   
Hardware: s390   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-26 12:47:10 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:
Attachments:
Description Flags
This is the compiled version of the program failing on rh 3.0
none
This is compiled on older RH system
none
This file still fails to open, any ideas ? none

Description sheryl sage 2004-05-06 20:57:58 UTC
We have compiled and linked with AS 2.1 and are trying to run out 
Netbackukp client  with these same binaries on RHEL 3 (base) and U2 
and we receive an abort message.  

When close a dynamically shared library (w/C++ objects) is always 
aborts.  Attached is the program that reproduced the event.  This 
program is compiled and works fine on RH 2.1.  When we run it on RH 
3.0 is aborts on the dlclose step.

Steps to Reproduce:
1. Run program


This is the program written to demonstrate the problem.


#include <dlfcn.h>

#define NULL 0


main(int argc, char *argv[])
{
        void    *handle = NULL;
        char    path[1000];
        int     status = 0;

        if (argc != 2)
        {
                printf("Usage: %s <dynamic lib>\n", argv[0]);
                exit(1);
        }

        strcpy(path, argv[1]);

        printf("Trying dlopen of %s\n", path);

        handle = dlopen(path, RTLD_LAZY);
        if (handle == NULL) {
                printf("dlopen failed\n");
                printf("dlerror -  %s\n", dlerror());
                exit(2);
        } else {
                printf("dlopen succeeded... handle %d\n", (int)
handle);
        }

        printf("Trying dlclose of %s handle %d\n", path, (int)handle);

        status = dlclose(handle);
        if (status != 0) {
                printf("dlclose failed\n");
                exit(2);
        } else {
                printf("dlclose succeeded\n");
        }

        exit(0);
}

zvmrh58 - rh 2.1 host
glibc 2.2.4
gcc 2.95.3

zvmrh56 - rh 3.0 host
glibc 2.3.2
gcc 3.2.3 

compiled using (on host zvmrh58)
/usr/bin/cc -o zlinux58 -lnsl -lresolv -ldl zlinux58.c

FTP'd the compiled program to host zvmrh56

./zlinux58 /lib/libgcc_s-3.2.3-20030829.so.1
Trying dlopen of /lib/libgcc_s-3.2.3-20030829.so.1
dlopen succeeded... handle 4201504
Trying dlclose of /lib/libgcc_s-3.2.3-20030829.so.1 handle 4201504
dlclose succeeded

./zlinux58 /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
dlopen succeeded... handle 4201512
Trying dlclose of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so handle 
4201512
Aborted

Comment 1 Jakub Jelinek 2004-05-13 15:19:15 UTC
Is the arch really s390x (i.e. 64-bit)?
Then the paths would be /usr/lib64/libstdc++*.

Comment 2 Domingo Cardenas 2004-05-14 22:03:15 UTC
No this is s390, the 31-bit version of RedHat

Comment 3 Domingo Cardenas 2004-05-14 22:06:55 UTC
No the platform is really s390, it's the 31-bit version of RedHat.

Comment 4 Jakub Jelinek 2004-05-25 13:49:08 UTC
AFAIK there was no such thing as AS2.1 for s390, only 7.2/s390.
Anyway, I have compiled/linked your testcase on 7.3/s390:
$ rpm -q gcc glibc
gcc-2.95.3-0.72
glibc-2.2.4-24.2
and run on 3.0E-U2:
$ rpm -q gcc glibc compat-libstdc++
gcc-3.2.3-34
glibc-2.3.2-95.20
compat-libstdc++-7.2-2.95.3.78
$ for i in /lib/libgcc_s* /usr/lib/libstdc++*; do /tmp/T $i; echo $?; done
Trying dlopen of /lib/libgcc_s-3.2.3-20040414.so.1
dlopen succeeded... handle 4201504
Trying dlclose of /lib/libgcc_s-3.2.3-20040414.so.1 handle 4201504
dlclose succeeded
0
Trying dlopen of /lib/libgcc_s.so.1
dlopen succeeded... handle 4201488
Trying dlclose of /lib/libgcc_s.so.1 handle 4201488
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
dlopen succeeded... handle 4201512
Trying dlclose of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so handle 4201512
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
dlopen succeeded... handle 4201512
Trying dlclose of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so handle 4201512
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++-libc6.1-2.so.3
dlopen succeeded... handle 4201504
Trying dlclose of /usr/lib/libstdc++-libc6.1-2.so.3 handle 4201504
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++-libc6.2-2.so.3
dlopen succeeded... handle 4201504
Trying dlclose of /usr/lib/libstdc++-libc6.2-2.so.3 handle 4201504
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++.so.5
dlopen succeeded... handle 4201496
Trying dlclose of /usr/lib/libstdc++.so.5 handle 4201496
dlclose succeeded
0
Trying dlopen of /usr/lib/libstdc++.so.5.0.3
dlopen succeeded... handle 4201496
Trying dlclose of /usr/lib/libstdc++.so.5.0.3 handle 4201496
dlclose succeeded
0

Comment 5 Domingo Cardenas 2004-06-01 23:56:50 UTC
Ok 7.2 (kernel level 2.4.9-37) is where I compile the program,
it works fine on 7.2.  Now FTP the compiled program to 7.3 
(kernel level 2.4.21-4.EL).  I know it works if I recompile
the code on 7.3.  I want it to work WITHOUT recompiling the
code.  It works for most libraries, but if the library has
C++ objects in it, the dlclose fails.  In this case
/usr/lib/libstdc++-3-libc6.1-2-2.10.0.so

Comment 6 Steve Hedberg 2004-06-22 19:10:46 UTC
We think we have supplied you all you need. If you need more info, 
please tell us what you need.  This is a showstopper for Veritas 
NetBackup support of Red Hat 3.0 on the Z-Series hardware.

Comment 7 sheryl sage 2004-06-22 21:17:04 UTC
Should we have a call to discuss this.  Adding Greg Nuss to the 
distribution list.  Greg, can you organize the right people from 
redhat to talk about this with our netbackup team.  thanks - sheryl -

Comment 8 Jakub Jelinek 2004-06-22 21:46:15 UTC
Can you perhaps attach zlinux58 binary which fails in RHEL3?

Comment 9 Domingo Cardenas 2004-06-22 23:36:43 UTC
Created attachment 101348 [details]
This is the compiled version of the program failing on rh 3.0

Comment 10 Jakub Jelinek 2004-06-23 08:49:17 UTC
Sorry, still can't reproduce.
$ rpm -q glibc gcc compat-libstdc++; for i in /lib/libgcc_s* /usr/lib/libstdc++*; do \
ls -l $i; md5sum $i; /tmp/zlinuxtest $i; echo $?; done
glibc-2.3.2-95.21
gcc-3.2.3-37
compat-libstdc++-7.2-2.95.3.78
-rwxr-xr-x    1 root     root        45152 Jun 18 17:37 /lib/libgcc_s-3.2.3-20040414.so.1
c3f16106d956f0aa2ed3d2dfb89702c5  /lib/libgcc_s-3.2.3-20040414.so.1
Trying dlopen of /lib/libgcc_s-3.2.3-20040414.so.1
dlopen succeeded... handle 4202544
Trying dlclose of /lib/libgcc_s-3.2.3-20040414.so.1 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           28 Jun 18 18:38 /lib/libgcc_s.so.1 -> libgcc_s-3.2.3-20040414.so.1
c3f16106d956f0aa2ed3d2dfb89702c5  /lib/libgcc_s.so.1
Trying dlopen of /lib/libgcc_s.so.1
dlopen succeeded... handle 4202528
Trying dlclose of /lib/libgcc_s.so.1 handle 4202528
dlclose succeeded
0
-rwxr-xr-x    1 root     root         1804 Nov  6  2003 /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
dlopen succeeded... handle 4202552
Trying dlclose of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so handle 4202552
dlclose succeeded
0
-r-xr-xr-x    1 root     root       373228 Nov  6  2003 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
d0c7cf29f7ca63d7a880fabf80d4b6af  /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
dlopen succeeded... handle 4202552
Trying dlclose of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so handle 4202552
dlclose succeeded
0
lrwxrwxrwx    1 root     root           31 May 13 11:13 /usr/lib/libstdc++-libc6.1-2.so.3 -> libstdc++-3-libc6.1-2-2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-libc6.1-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.1-2.so.3
dlopen succeeded... handle 4202544
Trying dlclose of /usr/lib/libstdc++-libc6.1-2.so.3 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           31 May 13 11:13 /usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so
d0c7cf29f7ca63d7a880fabf80d4b6af  /usr/lib/libstdc++-libc6.2-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.2-2.so.3
dlopen succeeded... handle 4202544
Trying dlclose of /usr/lib/libstdc++-libc6.2-2.so.3 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           18 Jun 18 18:38 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.3
0cd6c456a420e3b171b22e588a5d080c  /usr/lib/libstdc++.so.5
Trying dlopen of /usr/lib/libstdc++.so.5
dlopen succeeded... handle 4202536
Trying dlclose of /usr/lib/libstdc++.so.5 handle 4202536
dlclose succeeded
0
-rwxr-xr-x    1 root     root       789016 Jun 18 17:37 /usr/lib/libstdc++.so.5.0.3
0cd6c456a420e3b171b22e588a5d080c  /usr/lib/libstdc++.so.5.0.3
Trying dlopen of /usr/lib/libstdc++.so.5.0.3
dlopen succeeded... handle 4202536
Trying dlclose of /usr/lib/libstdc++.so.5.0.3 handle 4202536
dlclose succeeded
0

Can you run the same command on RHEL3 U2 and give results?

Comment 11 Domingo Cardenas 2004-06-23 15:05:33 UTC
Created attachment 101359 [details]
This is compiled on older RH system

Sorry the previous attachment was compiled on rh 3.0, so it works fine.
This is the failing version compiled on the older RH system.  Notice
the name zlinux58, same program listed in the beginning of this report

Comment 12 Jakub Jelinek 2004-06-23 15:15:07 UTC
Still works:

$ rpm -q glibc libgcc compat-libstdc++; md5sum /tmp/zlinux58; for i in /lib/libgcc_s* /usr/lib/libstdc++*; do \
ls -l $i; md5sum $i; /tmp/zlinux58 $i; echo $?; done
glibc-2.3.2-95.21
libgcc-3.2.3-37
compat-libstdc++-7.2-2.95.3.78
2a227bf8b46376a6d769430c3b6f4684  /tmp/zlinux58
-rwxr-xr-x    1 root     root        45152 Jun 18 17:37 /lib/libgcc_s-3.2.3-20040414.so.1
c3f16106d956f0aa2ed3d2dfb89702c5  /lib/libgcc_s-3.2.3-20040414.so.1
Trying dlopen of /lib/libgcc_s-3.2.3-20040414.so.1
dlopen succeeded... handle 4202544
Trying dlclose of /lib/libgcc_s-3.2.3-20040414.so.1 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           28 Jun 18 18:38 /lib/libgcc_s.so.1 -> libgcc_s-3.2.3-20040414.so.1
c3f16106d956f0aa2ed3d2dfb89702c5  /lib/libgcc_s.so.1
Trying dlopen of /lib/libgcc_s.so.1
dlopen succeeded... handle 4202528
Trying dlclose of /lib/libgcc_s.so.1 handle 4202528
dlclose succeeded
0
-rwxr-xr-x    1 root     root         1804 Nov  6  2003 /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
dlopen succeeded... handle 4202552
Trying dlclose of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so handle 4202552
dlclose succeeded
0
-r-xr-xr-x    1 root     root       373228 Nov  6  2003 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
d0c7cf29f7ca63d7a880fabf80d4b6af  /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
dlopen succeeded... handle 4202552
Trying dlclose of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so handle 4202552
dlclose succeeded
0
lrwxrwxrwx    1 root     root           31 May 13 11:13 /usr/lib/libstdc++-libc6.1-2.so.3 -> libstdc++-3-libc6.1-2-2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-libc6.1-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.1-2.so.3
dlopen succeeded... handle 4202544
Trying dlclose of /usr/lib/libstdc++-libc6.1-2.so.3 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           31 May 13 11:13 /usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so
d0c7cf29f7ca63d7a880fabf80d4b6af  /usr/lib/libstdc++-libc6.2-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.2-2.so.3
dlopen succeeded... handle 4202544
Trying dlclose of /usr/lib/libstdc++-libc6.2-2.so.3 handle 4202544
dlclose succeeded
0
lrwxrwxrwx    1 root     root           18 Jun 18 18:38 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.3
0cd6c456a420e3b171b22e588a5d080c  /usr/lib/libstdc++.so.5
Trying dlopen of /usr/lib/libstdc++.so.5
dlopen succeeded... handle 4202536
Trying dlclose of /usr/lib/libstdc++.so.5 handle 4202536
dlclose succeeded
0
-rwxr-xr-x    1 root     root       789016 Jun 18 17:37 /usr/lib/libstdc++.so.5.0.3
0cd6c456a420e3b171b22e588a5d080c  /usr/lib/libstdc++.so.5.0.3
Trying dlopen of /usr/lib/libstdc++.so.5.0.3
dlopen succeeded... handle 4202536
Trying dlclose of /usr/lib/libstdc++.so.5.0.3 handle 4202536
dlclose succeeded
0

What glibc, libgcc and compat-libstdc++ versions do you use?

Comment 13 Domingo Cardenas 2004-06-23 15:33:35 UTC
rpm -q glibc libgcc compat-libstdc++; md5sum ./zlinux58; for i 
in /lib/libgcc_s* /usr/lib/libstdc++*; do \
> ls -l $i; md5sum $i; ./zlinux58 $i; echo $?; done
glibc-2.3.2-95.3
libgcc-3.2.3-20
compat-libstdc++-7.2-2.95.3.77
2a227bf8b46376a6d769430c3b6f4684  ./zlinux58
-rwxr-xr-x    1 root     root        43720 Sep 16  2003 /lib/libgcc_s-
3.2.3-20030829.so.1
3e8d517185ed1ceca4c8008398273dcd  /lib/libgcc_s-3.2.3-20030829.so.1
Trying dlopen of /lib/libgcc_s-3.2.3-20030829.so.1
dlopen succeeded... handle 4201504
Trying dlclose of /lib/libgcc_s-3.2.3-20030829.so.1 handle 4201504
dlclose succeeded
0
lrwxrwxrwx    1 root     root           28 Apr  7 
12:59 /lib/libgcc_s.so.1 -> libgcc_s-3.2.3-20030829.so.1
3e8d517185ed1ceca4c8008398273dcd  /lib/libgcc_s.so.1
Trying dlopen of /lib/libgcc_s.so.1
dlopen succeeded... handle 4201488
Trying dlclose of /lib/libgcc_s.so.1 handle 4201488
dlclose succeeded
0
-rwxr-xr-x    1 root     root         1804 Sep 17  
2003 /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-3-libc6.1-2-
2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
dlopen succeeded... handle 4201512
Trying dlclose of /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so handle 
4201512
Aborted
134
-r-xr-xr-x    1 root     root       372786 Sep 17  
2003 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
862cdfb5ad50040a6ff2e9efcb2903e1  /usr/lib/libstdc++-3-libc6.2-2-
2.10.0.so
Trying dlopen of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
dlopen succeeded... handle 4201512
Trying dlclose of /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so handle 
4201512
Aborted
134
lrwxrwxrwx    1 root     root           31 Apr  7 
13:47 /usr/lib/libstdc++-libc6.1-2.so.3 -> libstdc++-3-libc6.1-2-
2.10.0.so
979dd6536d0e5dcac919450c59e00af7  /usr/lib/libstdc++-libc6.1-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.1-2.so.3
dlopen succeeded... handle 4201504
Trying dlclose of /usr/lib/libstdc++-libc6.1-2.so.3 handle 4201504
Aborted
134
lrwxrwxrwx    1 root     root           31 Apr  7 
13:47 /usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-
2.10.0.so
862cdfb5ad50040a6ff2e9efcb2903e1  /usr/lib/libstdc++-libc6.2-2.so.3
Trying dlopen of /usr/lib/libstdc++-libc6.2-2.so.3
dlopen succeeded... handle 4201504
Trying dlclose of /usr/lib/libstdc++-libc6.2-2.so.3 handle 4201504
Aborted
134
lrwxrwxrwx    1 root     root           18 Apr  7 
13:02 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.3
c38f0d110e50df852cba444fee16664b  /usr/lib/libstdc++.so.5
Trying dlopen of /usr/lib/libstdc++.so.5
dlopen succeeded... handle 4201496
Trying dlclose of /usr/lib/libstdc++.so.5 handle 4201496
dlclose succeeded
0
-rwxr-xr-x    1 root     root       787432 Sep 16  
2003 /usr/lib/libstdc++.so.5.0.3
c38f0d110e50df852cba444fee16664b  /usr/lib/libstdc++.so.5.0.3
Trying dlopen of /usr/lib/libstdc++.so.5.0.3
dlopen succeeded... handle 4201496
Trying dlclose of /usr/lib/libstdc++.so.5.0.3 handle 4201496
dlclose succeeded
0


Comment 14 Jakub Jelinek 2004-06-23 15:39:27 UTC
Can you please upgrade glibc (to at least 2.3.2-95.20; it is the latest
RHEL3 errata glibc and was included in U2) and compat-libstdc++
(compat-libstdc++-7.2-2.95.3.78 is the latest RHEL3 errata and included in U1/U2)
and retry?

Comment 15 Domingo Cardenas 2004-06-23 16:08:11 UTC
I think you're confusing intel and s/390.  On the s/390 U2 disk I
have glibc-2.3.2-95.17.s390.rpm and compat-libstdc++-7.2-
2.95.3.78.s390.rpm.  I check RHN I can select, Intel-32, Intel-64
and, if I search for compat-libstdc, I get

Name Channel 
compat-libstdc++-7.3-2.96.118  Red Hat Linux 9 i386  
compat-libstdc++-7.3-2.96.110  Red Hat Linux 8.0 i386  
compat-libstdc++-6.2-2.9.0.16  Red Hat Linux 7.3 i386  
compat-libstdc++-6.2-2.9.0.16  Red Hat Linux 7.2 i386  
compat-libstdc++-7.3-2.96.128  Red Hat Enterprise Linux AS (v. 3 for 
x86)  
compat-libstdc++-7.3-2.96.123  Red Hat Enterprise Linux AS (v. 3 for 
x86)  
compat-libstdc++-7.3-2.96.122  Red Hat Enterprise Linux AS (v. 3 for 
x86)  
compat-libstdc++-6.2-2.9.0.16  Red Hat Enterprise Linux AS (v. 2.1 
for i386)  

There is no s390 version, not on RHN.  Where else would I look
to find these updates ?



Comment 16 Domingo Cardenas 2004-06-23 16:51:33 UTC
I used a different account on RHN.  I can see the s/390 isos.
Still same level of rpms, I have now.

Comment 17 Jakub Jelinek 2004-06-23 17:06:09 UTC
I'm not, both
https://rhn.redhat.com/errata/RHBA-2004-143.html
and
https://rhn.redhat.com/errata/RHBA-2003-356.html
include s390 packages.
If your RHN access is properly configured, you should be able to up2date
to those packages.

Comment 18 Domingo Cardenas 2004-06-23 20:08:14 UTC
Created attachment 101362 [details]
This file still fails to open, any ideas ?

I have verified the standard libraries from RedHat work fine now (ie I
can open and close them).  The development group still has an issue
with their file.  It is still aborting.  Any ideas on what I can do
to get past this error ?  

-rwxr-xr-x    1 root	 root	    211874 Apr	7 15:10 ./libVxSS_helper.so
9ae9c50a5478173ca8cef790cb52bf32  ./libVxSS_helper.so
Trying dlopen of ./libVxSS_helper.so
dlopen succeeded... handle 4201488
Trying dlclose of ./libVxSS_helper.so handle 4201488
Aborted
134

Thanks,
Domingo

Comment 19 Domingo Cardenas 2004-06-24 15:52:01 UTC
On the older 7.2 system the glib and gcc rpms are at
glibc-2.2.4-24.2
gcc-2.95.3-0.72
compat-libstdc++-2.10.0-1


Comment 20 Jakub Jelinek 2004-07-05 18:22:44 UTC
Ok, the problem seems to be serious bug in the 2.95ish toolchain,
particularly that __dso_handle which must be either non-existent,
or STV_HIDDEN is present, but STV_DEFAULT in /usr/lib/gcc-lib/*/*/crtbegin*.o.
for i in zlinux58 zlinuxtest libs390.so /usr/lib/libstdc++-libc6.2-2.so.3; do echo $i:; readelf -s $i | grep '__dso_handle\|^Symbol table'; done
zlinux58:
Symbol table '.dynsym' contains 14 entries:
     2: 00401ac0     0 OBJECT  GLOBAL DEFAULT   15 __dso_handle
Symbol table '.symtab' contains 112 entries:
    90: 00401ac0     0 OBJECT  GLOBAL DEFAULT   15 __dso_handle
zlinuxtest:
Symbol table '.dynsym' contains 11 entries:
Symbol table '.symtab' contains 75 entries:
    47: 00401994     0 OBJECT  GLOBAL HIDDEN   16 __dso_handle
libs390.so:
Symbol table '.dynsym' contains 480 entries:
   141: 0002a858     0 OBJECT  GLOBAL DEFAULT   17 __dso_handle
Symbol table '.symtab' contains 768 entries:
   429: 0002a858     0 OBJECT  GLOBAL DEFAULT   17 __dso_handle
/usr/lib/libstdc++-libc6.2-2.so.3:
Symbol table '.dynsym' contains 1423 entries:
Symbol table '.symtab' contains 1598 entries:
   178: 0003dab0     0 OBJECT  LOCAL  HIDDEN   13 __dso_handle

This has zero chance to work.
In gcc-2.95.3-0.72.src.rpm I see gcc-2.95.3-glibc224.patch patch which
introduces there __dso_handle symbol and has also .hidden __dso_handle
if HAVE_GAS_HIDDEN is defined, so my guess is that during the build of
that rpm the configury check for some reason failed.
I don't have access to any pre-RHEL3 s390* system now, so I can't verify it.

Anyway, what could help on the 7.2ish system is:
echo '.hidden __dso_handle' > /tmp/hide_dso_handle.s
as -o /tmp/hide_dso_handle.{o,s}
for i in crtbegin crtbeginS; do ld -r -o /tmp/$i.o `gcc -print-file-name=$i.o` /tmp/hide_dso_handle.o; done

Now verify with readelf -s /tmp/crtbegin*.o that __dso_handle is HIDDEN,
not DEFAULT and if so, make a backup copy of the
`gcc -print-file-name=crtbegin.o` (resp. crtbeginS.o) and copy /tmp/crtbegin.o
(resp. /tmp/crtbeginS.o) over it.
Now I believe relinking all programs/shared libraries should make them
workable on both 7.2ish systems and RHEL3/RHEL4/...

Comment 21 Ulrich Drepper 2004-08-26 06:10:33 UTC
I'll change the category, it's a gcc issue.

Beside, did you try what Jakub suggested?

Comment 22 Jakub Jelinek 2004-10-26 12:47:10 UTC
I don't think there is any point to keep this bug open anymore.
We can't retroactively fix a bug in a product that is not supported
anymore and the commands I posted above should IMHO cure it.