User reported issue:
Hi! I am trying to install .NET Core in my Fedora 25 using the copr repository, however I get the following error: Error: nothing provides liblldb.so.3.8.1()(64bit) needed by dotnetcore- 1.1.0-6.fc25.x86_64 Any idea how to proceed? Thanks! - Alejandro
libldb is not in the requirements so it's probably pulled with AutoReq from one of the native libraries.
AutoReq
dotnetcore definitely requires lldb 3.8.1
dotnetcore
$ rpm -qp --requires dotnetcore-1.1.0-6.fc25.x86_64.rpm 2>/dev/null | grep ll liblldb.so.3.8.1()(64bit)
Interestingly enough, the version of lldb available in Fedora 25 is:
$ sudo dnf list lldb Last metadata expiration check: 0:07:34 ago on Thu Mar 16 17:13:44 2017. Installed Packages lldb.x86_64 3.9.1-1.fc25 @updates Available Packages lldb.i686 3.9.1-1.fc25 updates
But 3.8.1 was available previously
@nmilosev, looks like .NET Core was built against lldb 3.8.1 but the version now available in Fedora repos is 3.9.1. A quick fix would be to simply rebuild the package against 3.9.1 (just a version bump + copr build). We should also find out the lldb update policy in Fedora and try to avoid this surprise in the future.
Oh, another option is to filter out the automatically generated requires. I am against that, especially if the much simpler fix of just rebuilding it fixes the issue.
I agree, new build:
https://copr.fedorainfracloud.org/coprs/nmilosev/dotnet-sig/build/527912/
Hopefully this fixes it.
Thanks, it does fix the issue afaict:
$ sudo dnf install dotnetcore --downloadonly --refresh RCM Tools for Fedora 25 (RPMs) 7.7 kB/s | 3.3 kB 00:00 Copr repo for dotnet-sig owned by nmilosev 59 kB/s | 29 kB 00:00 Copr repo for openjdk9 owned by omajid 277 kB/s | 208 kB 00:00 Fedora 25 openh264 (From Cisco) - x86_64 5.3 kB/s | 3.0 kB 00:00 Dependencies resolved. ======================================================================================= Package Arch Version Repository Size ======================================================================================= Installing: dotnetcore x86_64 1.1.0-7.fc25 nmilosev-dotnet-sig 44 M Transaction Summary ======================================================================================= Install 1 Package Total download size: 44 M Installed size: 117 M Is this ok [y/N]:
Can this be closed now?
Yes, sorry. We just have to watch for new versions.
Metadata Update from @rhea: - Issue assigned to rhea
Metadata Update from @rhea: - Assignee reset
Metadata Update from @rhea: - Issue tagged with: bug, package
Metadata Update from @omajid: - Issue assigned to nmilosev - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Samael Bate singingbush@hotmail.com May 21 (2 days ago)
to nmilosev on recent Fedora 26 install I see the following when attempting install of dotnet following your instructions:
Last metadata expiration check: 0:03:43 ago on Sun May 21 22:08:56 2017 BST. Error: conflicting requests - nothing provides liblldb.so.3.9.0()(64bit) needed by dotnetcore-1.1.0-7.fc26.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages)
i tried installing lldb-devel as well but that didn't help.
Metadata Update from @nmilosev: - Issue status updated to: Open (was: Closed)
User reported the above, time to restart build again?
https://copr.fedorainfracloud.org/coprs/nmilosev/dotnet-sig/build/555717/
Fedora 26 and 27 just moved to lldb 4.0:
https://koji.fedoraproject.org/koji/packageinfo?packageID=21851
It's worth kicking off a rebuild. If it works, great. If not, we get to find out what's broken.
I am totally lost why the build failed on rawhide.
The error message is:
coreclr/src/pal/inc/pal.h:6002:22: error: definition of builtin function '_rotr' unsigned int __cdecl _rotr(unsigned int value, int shift)
But that definition is guarded by a __has_builtin(_rotr):
__has_builtin(_rotr)
#if !__has_builtin(_rotr) /*++ Function: _rotr See MSDN doc. --*/ EXTERN_C PALIMPORT inline unsigned int __cdecl _rotr(unsigned int value, int shift)
I tried this in a rawhide VM just now and I can't reproduce this. Maybe the compiler got fixed? Maybe you can kick the build again to see if it does any better now?
Metadata Update from @rhea: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @rhea: - Issue assigned to nmilosev - Issue tagged with: bug, package
Login to comment on this ticket.