Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 893294 - ARM: error while loading shared libraries: libLLVM-3.1.so: cannot open shared object file: No such file or directory
Summary: ARM: error while loading shared libraries: libLLVM-3.1.so: cannot open shared...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: rawhide
Hardware: arm
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2013-01-09 04:02 UTC by Jens Petersen
Modified: 2013-01-24 02:42 UTC (History)
11 users (show)

Fixed In Version: llvm-3.1-13.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-24 02:05:55 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Jens Petersen 2013-01-09 04:02:39 UTC 
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-22 04:49:12 UTC 
I am still wondering if this is llvm specific or a ld.conf glibc ARM issue.
Comment 2 Jens Petersen 2013-01-22 04:51:14 UTC 
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 07:18:08 UTC 
(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-23 02:08:38 UTC 
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-23 02:11:25 UTC 
<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-23 02:11:56 UTC 
Will update here after testing the new build on ARM tomorrow.
Comment 7 Jens Petersen 2013-01-23 03:25:15 UTC 
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 05:32:42 UTC 
> 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 09:28:25 UTC 
I wanted clarification that this isn't an issue in F18 too
Comment 10 Jens Petersen 2013-01-23 09:40:43 UTC 
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 10:48:20 UTC 
(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 10:54:54 UTC 
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 11:20:49 UTC 
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-24 02:05:55 UTC 
ghc is building now finally for f19 arm.
Comment 15 Jens Petersen 2013-01-24 02:42:10 UTC 
(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?))
Note You need to log in before you can comment on or make changes to this bug.