Bug 380441
Summary: | [ppc] can't link with -m64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kirill Kolyshkin <kolyshkin> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 8 | CC: | ffesti, james.antill, pmatilai, pnasrat, tim.lauridsen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-03-13 07:38:09 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
Kirill Kolyshkin
2007-11-13 17:06:12 UTC
Initially I thought the problem is in absent libgcc.ppc64 package -- but I can not install it (so I assume the problem is elsewhere): [root@rpm-build-ppc64-f8 ~]# yum -y install libgcc.ppc64 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package libgcc.ppc64 0:4.1.2-33 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: libgcc ppc64 4.1.2-33 fedora 105 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 105 k Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Check Error: package libgcc-4.1.2-33 is already installed file /usr/sbin/libgcc_post_upgrade from install of libgcc-4.1.2-33 conflicts with file from package libgcc-4.1.2-33 Error Summary ------------- [root@rpm-build-ppc64-f8 ~]# Some more diags with strace: [root@rpm-build-ppc64-f8 ~]# strace -fF -eopen gcc -m64 conftest.c 2>&1 | grep gcc_s [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/ppc-redhat-linux/lib64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/ppc-redhat-linux/lib64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/local/lib64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/local/lib64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/lib64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/lib64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib64/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib64/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/ppc-redhat-linux/lib/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/ppc-redhat-linux/lib/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/local/lib/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/local/lib/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/lib/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/lib/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/libgcc_s.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 11448] open("/usr/lib/libgcc_s.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) /usr/bin/ld: cannot find -lgcc_s If yum/rpm say this conflicts, then it must be a yum/rpm bug. /usr/sbin/libgcc_post_upgrade is an ELF binary. Rpm only permits elf* and other multilib conflicts when the packages with conflicting files are installed in the same transaction. In other words: # rpm -e --nodeps libgcc # yum install libgcc Yum should now bring in both archs without conflicts. If you think the behavior is nutty, you're not alone... see bug 190209. (In reply to comment #4) > In other words: > # rpm -e --nodeps libgcc > # yum install libgcc For the sake of other people reading this bug. Oh my, I should've tried that on a dummy first... [root@rpm-build-ppc64 /]# rpm -e --nodeps libgcc [root@rpm-build-ppc64 /]# yum install libgcc There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: libgcc_s.so.1: cannot open shared object file: No such file or directory .... (In reply to comment #4) > Rpm only permits elf* and other multilib conflicts when the packages with > conflicting files are installed in the same transaction. > > In other words: > # rpm -e --nodeps libgcc > # yum install libgcc OK, the correct thing to do would be # rpm -e --justdb libgcc # yum install libgcc Sorry, these are the correct commands: # rpm -e <s>justdb </s>nodeps libgcc # yum install libgcc Sorry, these are the correct commands: # rpm -e --justdb --nodeps libgcc # yum install libgcc My next problem is [root@rpm-build-ppc64 packages]# ls -l glibc-2* glibc-devel-2.6-4.ppc* -rw-r--r-- 1 root root 7848095 Jul 11 17:42 glibc-2.6-4.ppc.rpm -rw-r--r-- 1 root root 7803131 Jul 11 17:42 glibc-2.6-4.ppc64.rpm -rw-r--r-- 1 root root 2750742 Jul 11 17:42 glibc-devel-2.6-4.ppc.rpm -rw-r--r-- 1 root root 2788741 Jul 11 17:42 glibc-devel-2.6-4.ppc64.rpm [root@rpm-build-ppc64 packages]# rpm -ihv glibc-2* glibc-devel-2.6-4.ppc* Preparing... ########################################### [100%] file /sbin/ldconfig conflicts between attempted installs of glibc-2.6-4 and glibc-2.6-4 file /sbin/sln conflicts between attempted installs of glibc-2.6-4 and glibc-2.6-4 file /usr/sbin/iconvconfig conflicts between attempted installs of glibc-2.6-4 and glibc-2.6-4 I think this is the same as before. reassinging over to rpm though I'm not sure there's anything to be done there, either. Is there anything I can do about it? I need to setup an environment where I can compile both with and without -m64. Is it possible at all? Is this a problem of glibc packaging? Repository? RPM? For any such conflicts, follow the same recipe from comment #8 to get packages for both archs installed. Depends on your situation of course, but might be less of a fuss to just reinstall from scratch to get all the necessary bits into the same transaction. Nothing to fix in rpm (or yum) here, other than long-term ban the "sharing" of conflicting files on multilib too. For now this is expected behavior though. (In reply to comment #12) > For any such conflicts, follow the same recipe from comment #8 to get packages > for both archs installed. Depends on your situation of course, but might be less > of a fuss to just reinstall from scratch to get all the necessary bits into the > same transaction. Yeah, I did follow the recipe in comment #8 but when I got the problem described in comment #9. To my understanding this can not be solved and therefore a bug. All right, let me do yet another round of investigation and I will follow up in a new bug I guess. (In reply to comment #13) > All right, let me do yet another round of investigation and I will follow up in > a new bug I guess. (In reply to comment #13) > All right, let me do yet another round of investigation and I will follow up in > a new bug I guess. For the record, it's bug #437251. |