Bug 893294

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: llvmAssignee: Jens Petersen <petersen>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: bos, codonell, dmalcolm, jakub, law, michel, pbrobinson, pfrankli, schwab, scottt.tw, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Unspecified   
Whiteboard:
Fixed In Version: llvm-3.1-13.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-23 21:05:55 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418    

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?))