#15 liblldb dependency issue
Closed: Fixed None Opened 7 years ago by nmilosev.

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.

dotnetcore definitely requires lldb 3.8.1

$ 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.

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)

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

#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

5 years ago

Login to comment on this ticket.

Metadata