Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ARM: error while loading shared libraries: libLLVM-3.1.so: cannot open shared object file: No such file or directory|
|Product:||[Fedora] Fedora||Reporter:||Jens Petersen <petersen>|
|Component:||llvm||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||bos, codonell, dmalcolm, jakub, law, michel, pbrobinson, pfrankli, schwab, scottt.tw, spoyarek|
|Fixed In Version:||llvm-3.1-13.fc19||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-23 21:05:55 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jens Petersen 2013-01-08 23:02:39 EST
Description of problem: Not quite sure what the cause it but llvm tools seems not to work currently for ARM since they somehow can't find libLLVM-3.1.so. Version-Release number of selected component (if applicable): llvm-3.1-12.fc19.armv7hl How reproducible: 100% Steps to Reproduce: 1. Try to build package that BR llvm 2. in ARM rawhide try to run llc or opt, etc 3. ldd llc Actual results: 1. http://arm.koji.fedoraproject.org/koji/getfile?taskID=1356979&name=build.log&offset=-4000 2. # opt opt: error while loading shared libraries: libLLVM-3.1.so: cannot open shared object file: No such file or directory # llc llc: error while loading shared libraries: libLLVM-3.1.so: cannot open shared object file: No such file or directory 3. # ldd /usr/bin/llc | grep LLVM libLLVM-3.1.so => not found Expected results: llvm tools to find libLLVM-3.1.so Additional info: It is working fine in F18 so must be some F19 specific ARM problem. Not sure why /etc/ld.so.conf.d/llvm-arm.conf is being "ignored" in F19.
Comment 1 Jens Petersen 2013-01-21 23:49:12 EST
I am still wondering if this is llvm specific or a ld.conf glibc ARM issue.
Comment 2 Jens Petersen 2013-01-21 23:51:14 EST
I wanted to try to test tix for example but right now F19 ARM is broken (policycoreutils version conflict with selinux-policy).
Comment 3 Peter Robinson 2013-01-22 02:18:08 EST
(In reply to comment #2) > I wanted to try to test tix for example but right now F19 ARM is broken > (policycoreutils version conflict with selinux-policy). Should now be fixed, I actually fixed it yesterday but we've a severe lack of newRepo hosts so it's taking a while
Comment 4 Jens Petersen 2013-01-22 21:08:38 EST
bconoboy suggested this issue was a temporarily toolchain problem at the time and probably fixed now if ones rebuilds. So I went ahead and bumped now to llvm-3.1-13.fc19. http://koji.fedoraproject.org/koji/taskinfo?taskID=4895310 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1381294
Comment 5 Jens Petersen 2013-01-22 21:11:25 EST
<bconoboy> Well, it happened with mysql, and one other library (don't remember which) Anyway likely this is already fixed in F19 Rawhide but reassigning to glibc which provides ldconfig just for reference and completeness.
Comment 6 Jens Petersen 2013-01-22 21:11:56 EST
Will update here after testing the new build on ARM tomorrow.
Comment 7 Jens Petersen 2013-01-22 22:25:15 EST
Further note this is purely an F19 issue so I don't think it should be on the F18ARMBLocker list. Peter?
Comment 8 Jens Petersen 2013-01-23 00:32:42 EST
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4895310 This failed to complete due to some old pod markup problems, which the new perl-Pod-Parser seems more strict about. Should be fixed in: http://koji.fedoraproject.org/koji/taskinfo?taskID=4895618 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1381686
Comment 9 Peter Robinson 2013-01-23 04:28:25 EST
I wanted clarification that this isn't an issue in F18 too
Comment 10 Jens Petersen 2013-01-23 04:40:43 EST
Okay armv5tel build is still in progress but I confirmed that this issue is fixed with llvm-3.1-13.fc19.armv7hl on armv7hl f19 rawhide. (Note again for F18 Blocker people this issue does not affect F18.)
Comment 11 Jens Petersen 2013-01-23 05:48:20 EST
(In reply to comment #9) > I wanted clarification that this isn't an issue in F18 too Ok thanks. I believe this ARM problem has never been seen on F18 only on F19 Rawhide. And it is not occurring for current F18 so it seems safe to remove F18ARMBlocker. Discussion earlier today UTC (last night US EST) on #fedora-arm: <bconoboy> We've run into a handful of packages where the library was stored under /usr/lib/somedir/library.so and it couldn't be found. Rebuilding the package solved the problem. : <bconoboy> My assumption is that the package was built under some faulty dependency <juhp> pbrobinson also recommended same : <bconoboy> Well, it happened with mysql, and one other library (don't remember which) : <juhp> only for rawhide? <bconoboy> haven't seen it on fc18 <juhp> aha <bconoboy> the fact that it works now suggests to me that whatever it was happened during an intermediate build version <juhp> ah okay so it might be fixed already? <bconoboy> believe so Above build seems also to corroborate this.
Comment 12 Jens Petersen 2013-01-23 05:54:54 EST
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=108968 is the completed build of llvm-3.1-13.fc19.
Comment 13 Jens Petersen 2013-01-23 06:20:49 EST
Just to confirm I tested f18 llvm by hand now and indeed this problem is not seen. As expected, since we have not been seeing it at all in f18 koji either.
Comment 14 Jens Petersen 2013-01-23 21:05:55 EST
ghc is building now finally for f19 arm.
Comment 15 Jens Petersen 2013-01-23 21:42:10 EST
(moved component back to llvm since the toolchain problem that caused this bug seems to have been long fixed and it is not clear anyway which component it was (binutils?))