Core: rpm dependency problems after visual studio update

[ahmedowsky]

I am developing a dotnet core 2.0 app, a web api to be specific. It was running on a x86_64 centos7 machine. Before i perform an update for Visual Studio's new version (i don't know how old my latest version was), i was able to build rpm packages on the linux machine i just mentioned and i was able to install them with a 'libc.so.6' dependency.

'libc.so.6' dependency was not my choice, i didn't even know that i needed 'libc.so.6' until my first time installing the rpm i built (x86_64 arch). I've resolved that dependency problem by installing 'glibc.i686'. Everything was working fine; i was able to build rpms, install them, run my app without a problem...

Than i updated visual studio... (btw it's VS-2017)

Now, after the update, i'm having a few more dependency issues, just because i've updated visual studio.

error: Failed dependencies:
libdl.so.2(GLIBC_2.17)(64bit) is needed by ...
libdl.so.2(GLIBC_2.4) is needed by ...
libgcc_s.so.1 is needed by ...
libgcc_s.so.1(GCC_3.5) is needed by ...
libpthread.so.0(GLIBC_2.17)(64bit) is needed by ...

_I don't even know why i need glibc 2.17 & 2.4 both_ but i know i have glibc 2.17 64bit already installed. I thought; maybe the issue might be having 'glibc.i686' along with 'glibc.x86_64' so i removed i686 buuut this made things even worse and i ended up with more dependency problems.

I also installed gcc, updated yum, installed dotnet core 2.2 on linux machine, i moved the project to dotnet core 2.2, i tried to install rpm's over my repository (hoping that maybe yum can resolve/install those dependencies). Nothing changed.

Just because i've updated visual studio. Soo my questions are; "what's happening?" and "how can i fix it?".
Let me know if you need more details.

[omajid]

Let's see if we can break this problem down into smaller problems.

x86_64 centos7

Just for the record, can you show us the output of /etc/os-release ?

the rpm i built (x86_64 arch)

Can you tell us a bit more? What is this RPM? What does the spec file look like? How are you building the rpm? Can you reproduce this issue with a simple console project built by the RPM?

i'm having a few more dependency issues, just because i've updated visual studio

Does that mean you are building the .NET Core project on your Windows machine, and then copying the built project onto the CentOS machine and then wrapping it up in an RPM?

Can you show us the output of dotnet --info on Windows (where Visual Studio is installed) and on CentOS?

I don't even know why i need glibc 2.17 & 2.4 both

You don't. The dependency output just says which versions specify the features that the built rpm needs. A single version of glibc will provide multiple versions. On my machine, rpm -q --provides glibc | egrep '\(GLIBC_2\.[[:digit:]]' lists about 50 or so versions.

I also installed gcc, updated yum, installed dotnet core 2.2 on linux machine, i moved the project to dotnet core 2.2, i tried to install rpm's over my repository (hoping that maybe yum can resolve/install those dependencies). Nothing changed.

Please tell us how to reproduce this issue: the exact .NET Core code, project file, RPM spec file and the exact build steps you are running on the Windows box and on the CentOS box. Please do include the output and the error messages of each step where possible.

[ahmedowsky]

Sure

/etc/os-release output:

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

dotnet --info output (centos);

.NET Command Line Tools (2.0.0)
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9
Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64
Base Path: /usr/share/dotnet/sdk/2.0.0/
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

dotnet --info output (windows) | i was using that machine when i need the outputs because the other one i have (the one i am developing the app) caused me this dependency problem and at that moment i didn't have enough time to focus on that problem. This machine is the one i've updated the visual studio instance. Today i tried to install 2 different older versions of vs2017 on this one, both failed to reverse the situation.

.NET Core SDK (reflecting any global.json):
Version: 2.1.504
Commit: 91e160c7f0
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.504\
Host (useful for support):
Version: 2.1.8
Commit: 209f8aa25c
.NET Core SDKs installed:
2.0.0 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

dotnet --info output (the other windows i tried, development machine)

.NET Core SDK (reflecting any global.json):
Version: 2.2.104
Commit: 73f036d4ac
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.2.104\
Host (useful for support):
Version: 2.2.2
Commit: a4fd7b2c84
.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.2.104 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

I won't be able to share much about spec file's content (possible sensitive information) but i am the one who created it. This spec file handles a few simple tasks such as; setting up some firewall rules, executing bash and/or sql scripts (versioning/altering/backups etc). Spec/Rpm version information is being read from dll (dll's version). By doing so i am not changing the spec file at all between versions/releases. There's some kind of an automation there.

Yes, i also have a console application (same scenario, same everything, handles complex bl's) but it's not causing the same problem.

Yes, I am building the .NET Core project on my Windows machine, and then copying the built project onto the CentOS machine and then wrapping it up in an RPM, yes, exactly.

Project itself has a web api and a console app. They are both using some 3rd party dll's and handling some relatively complex tasks. They are both 2.0 apps. Web api is the one causing problems. The machines used in order to work on / develop those apps are all windows. The one i use to get the outputs is also a windows machine. I used that machine for more than 10 versions and god knows how many more releases without a problem.

Unfortunately i won't be able to share files with you.
--edit: correcting a misspelled word

[ahmedowsky]

Well i thought you might want to know about this
deplist command output has some interesting lines;

dependency: /bin/bash
provider: bash.x86_64 4.2.46-31.el7
dependency: /bin/sh
provider: bash.x86_64 4.2.46-31.el7
dependency: libc.so.6
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.0)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.1)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.1.3)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.14)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.17)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.2)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.3.4)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.3.4)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.4)
provider: glibc.i686 2.17-260.el7_6.3
dependency: libc.so.6(GLIBC_2.4)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libdl.so.2
provider: glibc.i686 2.17-260.el7_6.3
dependency: libdl.so.2()(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3

dependency: libdl.so.2(GLIBC_2.17)(64bit)
Unsatisfied dependency

dependency: libdl.so.2(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3

dependency: libdl.so.2(GLIBC_2.4)
Unsatisfied dependency

dependency: libgcc_s.so.1
provider: libgcc.i686 4.8.5-36.el7

dependency: libgcc_s.so.1(GCC_3.5)
Unsatisfied dependency

dependency: libm.so.6
provider: glibc.i686 2.17-260.el7_6.3
dependency: libm.so.6()(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libpthread.so.0
provider: glibc.i686 2.17-260.el7_6.3
dependency: libpthread.so.0()(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3

dependency: libpthread.so.0(GLIBC_2.17)(64bit)
Unsatisfied dependency

dependency: libpthread.so.0(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libpthread.so.0(GLIBC_2.3.2)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libpthread.so.0(GLIBC_2.3.3)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: libpthread.so.0(GLIBC_2.4)
provider: glibc.i686 2.17-260.el7_6.3
dependency: librt.so.1
provider: glibc.i686 2.17-260.el7_6.3
dependency: librt.so.1()(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: librt.so.1(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-260.el7_6.3
dependency: librt.so.1(GLIBC_2.4)
provider: glibc.i686 2.17-260.el7_6.3
dependency: ntp
provider: ntp.x86_64 4.2.6p5-28.el7.centos
dependency: rtld(GNU_HASH)
provider: glibc.x86_64 2.17-260.el7_6.3
provider: glibc.i686 2.17-260.el7_6.3

[ahmedowsky]

I got updates about this. Yesterday i created a new WebApi project (dotnet core 2.2) and the simplest spec file for it, built a rpm and tested that. Installation was successful, there were no such dependency problems. Then i noticed that project references were different between this test project & the one i faced dependency issues with.

Long story short, i changed target framework & references of my project (by references i mean dotnet packages published by microsoft). After that, dependency problems were no more but; right after i thought i've fixed the issue, i updated all installed nuget packages and that made dependency problems come back again, with more problematic packages this time.

Also i had to add _%define debug_package %{nil}_ line to my spec file after nuget updates.
I have no idea what's happening.

[omajid]

Is there any way you can try and extend your new WebApi project - say by adding those nuget references - until it produces the errors you are seeing in your main project? A way to reproduce the issue would be nice.

%define debug_package %{nil}

That tells RPM to not generate -debuginfo packages. It sounds like RPM is aborting the build because it sees that your package has no unmanaged/native (aka c/c++) debug information - which is expected. Can you share your dotnet publish command?

[karelz]

Are you able to reproduce same problem on more than one machine?
Can you please post clear simple repro steps? (minimal text please, just facts - long stories are hard to read and comprehend)

[ahmedowsky]

@karelz i know you are not reading, but @omajid does (thankfully). i'll provide more info about this issue soon but i already lost some serious time while trying to fix the problem so i need to keep working on what i was doing before that issue, for now. But i still am interested about the reason of that problem.

By then, i would appreciate if you would stay away from the issues i've opened if you are not going to read them :) like #2332

Thank you

[karelz]

@ahmedowsky I understand you may be frustrated by me not understanding, my appologies if I somehow caused that.
I'd just ask for a bit of perspective: Imagine for a second being in my role - trying to help people move issues forward, route them to the right places, dealing often times with dozens random issues per day. Many of them need quite a lot of back-and-forth for routing and some are not clear. Many are user-problems and I try to help sort those out to allow other engineers to focus on "real issues".
I'll be happy to help you route this issue to the right place (which is the main purpose of this repo) if you can help me understand what kind of problem you're facing.

If you don't want my help, that is perfectly fine - maybe @omajid will be able to help you (he is a good person and knows much more about Linux end-to-end scenarios than I do).
In such case I would appreciate clear information about what is status of the issue, next step, etc. If the issue sits for 1 week untouched, I assume it is ready to be closed (that is our typical rule on repos). That's why I poked at it after 5d of no reply.

I hope we can be respectful and civil to each other. I hope and believe that we both want just the best - to get the problem understood and ideally addressed, so let's try to make it happen. What do you say?

[ahmedowsky]

@karelz sorry, no, i'm frustrated by the issue itself. You are right. Please accept my apologies.

I understand you guys want some clear instructions to reproduce this issue but it might not be possible. Project is complex, spec file (rpm) is complex, +confidentiality.

@omajid is waiting for more details from me but i don't have enough time right now. Problem is not resolved, not properly at least. I will work on his last request (as soon as possible).

[karelz]

@ahmedowsky any udpate? ... it's been a month now.
If you don't have time now, that is ok. I would suggest to close the issue, until there is additional actionable information, then we can reopen it again.
What do you think?

[karelz]

No response, closing. Feel free to reopen when there's more info. Thanks!