Bug 132942
Summary: | Can not generate 64-bit binaries on ppc64 platform. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Dennis <dennis> |
Component: | gcc | Assignee: | 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
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. 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. 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. 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. 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. 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. 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. 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. |