Bug 132942

Summary: Can not generate 64-bit binaries on ppc64 platform.
Product: Red Hat Enterprise Linux 3 Reporter: Dennis <dennis>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-29 07:29:26 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 Dennis 2004-09-20 06:08:26 UTC
Description of problem:

The gcc/g++ compilers can not produce 64-bit code when used
with the -m64 flag (even with a simple program). Errors like
the following get output

"skipping incompatible /usr/lib/libm.so when searching for -lm"

Doing the same thing on an Opteron (x86_64) using Red Hat 
EL3 Update 2 is successfull. Actually -m32 and -m64 work
on the x86_64 platform.

However on the ppc64 platform only -m32 works.

How reproducible:

Always reproduceable.

Steps to Reproduce:
1. Save the following into hello.cc
#include <iostream>

int
main()
{
    std::cerr << "Hello world" << std::endl;

    return 0;
}
2. Compile with # g++ -m64 hello.cc
  
Actual results:

Compilation failures will result.

Expected results:

The expected result would be a 64-bit binary.

I am doing something wrong? How is a 64-bit binary
produced on a ppc64 platform running RH EL3U2?

Dennis.

Comment 1 Jakub Jelinek 2004-09-24 07:01:11 UTC
Do you have both .ppc.rpm and .ppc64.rpm glibc-devel installed?
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' \
  glibc glibc-common glibc-devel glibc-headers libgcc libstdc++ libstdc++-devel

Only glibc-common and glibc-headers should be for one arch only,
the remaining ones should be installed for both ppc and ppc64.

Comment 2 Dennis 2004-09-24 07:40:10 UTC
I carried out the suggestion. The following is the output
of the rpm command provided.

glibc-2.3.2-95.20.ppc
glibc-2.3.2-95.20.ppc64
glibc-common-2.3.2-95.20.ppc
glibc-devel-2.3.2-95.20.ppc
glibc-devel-2.3.2-95.20.ppc64
glibc-headers-2.3.2-95.20.ppc
libgcc-3.2.3-34.ppc
libgcc-3.2.3-34.ppc64
libstdc++-3.2.3-34.ppc
libstdc++-3.2.3-34.ppc64
libstdc++-devel-3.2.3-34.ppc
libstdc++-devel-3.2.3-34.ppc64

Your suggestion helped solve the initial problem. However,
there are still issues. Compilation with the following
parameters still fails.

# g++ -m64 hello.cc -luuid

this time with 

/usr/bin/ld: skipping incompatible /usr/lib/libuuid.so

errors.

Comment 3 Jakub Jelinek 2004-09-24 07:53:25 UTC
That means you don't have 64-bit libuuid.so installed.
That would be e2fsprogs-devel*.ppc64.rpm.
I'm not sure if that's included in the distribution though, only
selected libraries there are for both architectures.

If it is not in the distro, you can rebuild on your own,
e.g. grab e2fsprogs*.src.rpm corresponding to e2fsprogs you have installed,
rpmbuild --rebuild --target ppc64 e2fsprogs*.src.rpm and
install e2fsprogs-*.ppc64.rpm.

Comment 4 Dennis 2004-09-24 08:17:05 UTC
The appropriate 64-bit libuuid.so appears to exist on our
ppc64 installation.

# locate uuid.so
/usr/lib/libuuid.so
/lib/libuuid.so.1
/lib/libuuid.so.1.2
/lib64/libuuid.so.1
/lib64/libuuid.so.1.2

# file /lib64/libuuid.so.1.2
/lib64/libuuid.so.1.2: ELF 64-bit MSB shared object ....

As for e2fsprogs-devel, the installation CD comes with
only one package, that being e2fsprogs-devel-1.32-15.ppc.rpm.

I do notice that on RH EL3 x86_64 the above locate
produces

# locate uuid.so
/usr/lib64/libuuid.so
/lib64/libuuid.so.1
/lib64/libuuid.so.1.2

It looks like /usr/lib64/libuuid.so may be the key.

Note, I do have three source RPM disks, so I can carry
out your rpm command. However the weekend will get in the
way (I'm in Australia). 

In a couple of days I will let you know how things go.
I do appreciate the help very much.

Thanks.



Comment 5 Jakub Jelinek 2004-09-24 09:37:46 UTC
Well, as alternative to building e2fsprogs-devel*.ppc64.rpm, you could
just
for i in com_err e2p ext2fs ss uuid; do ln -sf /lib64/lib$i.so.[0-9] /usr/lib64/lib$i.so; done
The headers are already there from e2fsprogs-devel*.ppc.rpm, so
unless you need any of the .a libraries, symlinking should be enough.

Comment 6 Dennis 2004-09-27 08:08:07 UTC
The sym link suggestion has help me get further. 

Note, my aim is to produce a 64-bit version of our system
on ppc64 RH EL3.

Firstly, I get the following warnings when building a binary
that uses the uuid library

/usr/bin/ld: Warning: type of symbol `uuid_unparse' changed 
from 1 to 2 in 
/usr/lib/gcc-lib/ppc64-redhat-linux/3.2.3/../../../../lib64/libuuid.so

Any final solution (e.g Update 4) should try and prevent those
warnings. It does look like some extra sym linking needs to occur
or a few extra ppc64.rpm files need to be created.

Next issue was a missing symbolic link in the kerberos area

# ln -s /usr/kerberos/lib64/libgssapi_krb5.so.2.2
/usr/kerberos/lib64/libgssapi_krb5.so

The RH x86_64 release has the /usr/kerberos/lib64/libgssapi_krb5.so
link but the RH ppc64 build did not. 

The most serious issue now discovered is that it appears the
important _LP64 define is not set in gcc -m64 mode on ppc64.

For example try

# g++ -m64 -dM -E - < /dev/null | grep LP64

on ppc64 it is not set

on ia64 and x86_64 (Red Hat EL3 update 2) the flag
is set

# g++ -m64 -dM -E - < /dev/null | grep LP64
#define _LP64 1
#define __LP64__ 1

That flag on Unix (Linux and Solaris) indicates 64-bit
mode. I can try and work around the issue at the moment,
however I believe it to be important that _LP64 be
set correctly.

Sorry about dragging out this support item. We do want
our software to operate in 64-bit on ppc64, ia64 and x86_64
with Red Hat EL3 (we have ported to the last two already).

Side note, it appeats RH EL3 ppc64 runs a 64-bit kernel with
32-bit userland (e.g ls/gcc/rm etc). This differs from
x86_64 which runs a 64-bit kernel and 64-bit userland.
Just an observation. 

Thanks again.

Comment 7 Dennis 2004-09-29 06:25:31 UTC
A few more bits.

It looks like ssl needs the same fix as e2fsdevel, that is
there is no lib*ssl* in /usr/lib64 on ppc64, on x86_64 those
files exist.

A few more missing symbolic links
# ln -s /usr/lib64/libldap_r.so.2.0.17 /usr/lib64/libldap_r.so
# ln -s /usr/lib64/liblber.so.2.0.17 /usr/lib64/liblber.so

So in summary, to use gcc -m64 a few fixes need to be done
for RH EL 3 Update 4 or EL 4

(1) Add in missing files (e.g /usr/lib64/libssl.a).
(2) Add in missing symbolic links (e.g /usr/lib64/libuuid.so)
(3) Fix -m64 build to set _LP64 define.

I don't know whether this bugzilla item should persist. Maybe
it should be replaced by a series of new items each of
which addresses the items discovered by this bugzilla item.

Maybe even a little beta testing needs to occur, that is 
to see whether one can use '-m32' and '-m64' on ppc64.

Dennis.

Comment 8 Jakub Jelinek 2004-09-29 07:29:26 UTC
Yes, I think this should be closed.
You can file enhancement requests against the distribution component to request
*.ppc64.rpm versions of some devel packages that you needed (e2fsprogs-devel,
openldap-devel, etc.).

No standard covers _LP64 macro, the most portable way to detect
LP64 model is IMHO to #include <limits.h>
#include <stdint.h>
#if UINT_MAX == 0xffffffff && LONG_MAX = 0xffffffffffffffff && UINTPTR_MAX == LONG_MAX
... this is LP64
#endif
But GCC 3.4.x which is going to be RHEL4 compiler defines _LP64
and __LP64__ on targets that have 32-bit int and 64-bit long/pointers.