Bug 701586

Summary: c++ fails with errors if "-ldl" is not at end of parameter list
Product: Red Hat Enterprise Linux 6 Reporter: Frank Danapfel <fdanapfe>
Component: binutilsAssignee: Andreas Schwab <schwab>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: caecilie.hampel, elmar.billen, jakub, jan.kratochvil, linux, mnowak, pmuller, rdoty
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: binutils-2.20.51.0.2-5.21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 17:00:21 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 Frank Danapfel 2011-05-03 09:45:23 UTC
Description of problem:
We noticed a change in behaviour on PPC64 from RHEL5 => RHEL6 regarding the position of "-ldl" in the list compiler options.

The command

c++ -o foo  foo.o -lm -ldl -m64 -Wl,-melf64ppc libtest.a  -lpthread -lrt

succeeds on RHEL5 / SLES11SP0, on RHEL6 / SLES11SP1 it fails with errors like 
"libtest.a(some_object_file.o): undefined reference to `.dlerror'".

If we move the option "-ldl" to the end of compiler options, the command succeeds also on RHEL6. If "-ldl" is used twice (at the original position as well as at the end), the command also fails.

==> This problem currently blocks the SAP MaxDB validation for RHEL6 on PPC64!

As far as we know, this problem did not occur on x86 based platforms during the RHEL6 validation.

Version-Release number of selected component (if applicable):
gcc-c++-4.4.4-13.el6

How reproducible:
always

Steps to Reproduce:
see above
  
Actual results:


Expected results:


Additional info:

Comment 2 Jakub Jelinek 2011-05-03 11:33:16 UTC
I can confirm it, but it looks like a ppc ld bug in handling of the compatibility aixdesc ABI.
Shorter testcase:

rpm2cpio glibc-2.12*.ppc64.rpm | cpio -id
cd lib64
ln -sf libc-2.12.so libc.so
ln -sf libdl-2.12.so libdl.so
cat > test.c <<\EOF
extern char *dlerror (void);
volatile int i;

void _start (void)
{
  if (dlerror ())
    i++;
}
EOF
gcc -c -m64 test.c -o test.o
ld -o test -L . -ldl test.o -lc ./ld64.so.1
ld -o test -L . -ldl test.o -ldl -lc ./ld64.so.1
ld -o test -L . test.o -ldl -lc ./ld64.so.1
gcc -c -m64 -mcall=aixdesc -o test.o
ld -o test -L . -ldl test.o -lc ./ld64.so.1
ld -o test -L . -ldl test.o -ldl -lc ./ld64.so.1
ld -o test -L . test.o -ldl -lc ./ld64.so.1

Reproduced also with a cross-compiler (4.7 trunk from today) and cross-binutils (CVS HEAD from today).  Wonder why the *.a library is built with the old ABI though, AFAIK already RHEL4 GA switched from the .symbol stuff.

Comment 3 Elmar Billen 2011-05-03 13:14:29 UTC
(In reply to comment #2)

> Wonder why the *.a library is built with the old ABI
> though, AFAIK already RHEL4 GA switched from the .symbol stuff.

The problem occurs with several versions of the *.a library, the build environments for the libraries are:
SLES9 SP2, gcc 3.3.3, glibc-2.3.3-98-47 to
SLES9 SP4, gcc 4.1.2, glibc-2.3.3-98.94

- Elmar.

Comment 4 Jakub Jelinek 2011-05-03 13:22:42 UTC
Support for non-DOT_SYMBOLS first appeared in gcc 4.0 (and has been backported into gcc 3.4-RH (and perhaps some other compilers).  But the linker has to support it, so perhaps if SLES9 ld doesn't support those, then even gcc 4.1.2 built there won't support DOT_SYMBOLS.

Comment 5 RHEL Program Management 2011-05-04 06:00:33 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 6 Jakub Jelinek 2011-05-04 07:19:33 UTC
Alan Modra has fixed this upstream: http://sources.redhat.com/ml/binutils/2011-05/msg00044.html

Comment 17 errata-xmlrpc 2011-12-06 17:00:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1523.html