[ppc64le][.net7] Unhandled Exception: System.PlatformNotSupportedException: System.Data.ODBC is not supported on this platform #78563
Comments
ghost
added
the
|
Tagging subscribers to this area: @roji, @ajcvickers Issue DetailsDescriptionSupport for ppc64le architecture was added in .NET7. Using this, we were trying some sample code which uses System.Data.Odbc package. The sample code works on x86 machine with .NET7 but fails on ppc64le. The .csproj has the following: Project was created as follows: Sample code ( note: we are able to connect to the database using cli ) But on Power ppc64le machine we are getting below error During debugging what we found MSBuild::GetTargetPlatformIdentifier () may be returning empty string and this (https://github.com/dotnet/runtime/blob/main/src/libraries/System.Data.Odbc/src/System.Data.Odbc.csproj#L27) code throwing error. When we check the MSBuild repo https://github.com/dotnet/msbuild we don’t see ppc64le changes in eng/common/cross folder. https://github.com/dotnet/msbuild/blob/main/eng/common/README.md says "The files in this directory are shared by all Arcade repos and managed by automation. If you need to make changes to these files, open an issue or submit a pull request to https://github.com/dotnet/arcade first." -- Question @akoeplinger : Note: We opened the same issue in the arcade repo ( see dotnet/arcade#11675 ) but since we don't know if our analysis of root cause is right, opening it in the runtime repo also Tagging @omajid / @Sapana-Khemkar / @uweigand for awareness. Reproduction StepsOn a ppc64le machine
Expected behaviorBe able to connect to the database and retrieve data Actual behaviorRegression?No response Known WorkaroundsNo response ConfigurationOther informationNo response
|
|
The eng/common/cross changes are unrelated, those are for native code. I think the root cause is something else. The |
|
Can you please record a binlog and share it? I think it is somehow picking the wrong assembly from the nuget. |
will share bin logs tomorrow. |
|
@akoeplinger I could not record binlog for dotnet run but executed dotnet run --verbosity diag Below is my System.Data.Odbc package Am I missing something? |
|
Just an update, after enabling trace I getting below logs /usr/lib64/libmyodbc5.so this file is not there on my machine. Further investigation is in progress |
|
Adding some information based on what @janani66 and @uweigand shared with me over the last few days. The issue seems to be down to the missing On s390x (and similar on ppc64le, I assume) a |
|
Hmm. I can reproduce this on my Ubuntu system when building upstream However, on the same system, when I build the source-build tree (which also uses the non-portable RID), I get instead: It appears to me the difference is which input RID fallback graph is being used to generate the deps.json file. This happens in where Now, when building This is turn seems to be because of this line in which causes the Now, this makes me wonder if this is correct condition: maybe instead of checking for source-build mode, we should add the identifier whenever building in non-portable mode here? However, even so, this still doesn't explain why this does not work correctly in the RHEL RPM build, which does use source-build ... |
|
cc @tmds who recently touched |
|
I expect the |
|
It's not there: |
|
My current thinking is that 7.0.0 was missing #78395, which means the runtime.json graph didn't contain the target build RID for s390x/ppc64le and so arcade would filter through runtime.json and produce an empty runtime graph? |
|
If the target rids were not known in the source rid graph ("unknown rids"), with #78395 they will be added automatically. |
They are not on the 7.0 branch, and on main: for rhel, there is only x64 and arm64. #78395 is fixing the issue by patching |
Looks like the .NET 6 RPMs also completely lack the "runtimes" section in |
We need to make sure Microsoft.NETCore.App.deps.json has at least one runtime fallback graph. Otherwise, it is possible that .NET will fail to find assets placed in the RID-fallback graph. For more details, see dotnet/runtime#78563
Often rids are used to contain architecture specific artifacts, which wouldn't be available for s390x anyway. The changes that are in #78395 were backported by @ayakael to 6.0. |
We need to make sure Microsoft.NETCore.App.deps.json has a complete runtime fallback graph. Otherwise, it is possible that .NET will fail to find assets placed in paths based on the RID-fallback graph. For more details, see dotnet/runtime#78563
We need to make sure Microsoft.NETCore.App.deps.json has a complete runtime fallback graph. Otherwise, it is possible that .NET will fail to find assets placed in paths based on the RID-fallback graph. For more details, see dotnet/runtime#78563
|
To confirm that missing RIDs in the graph were the root cause of the issue, I manually added |
|
I am trying to apply #78395 on top of 7.0.0 (along with the other patch files at https://gitlab.com/redhat/centos-stream/rpms/dotnet7.0/), and running into a build issue while building Any ideas @tmds ? Am I missing another fix in 7.0? If I can't backport the PR itself, I suppose we will have to wait until a future 7.0 release to pick up the fix? |
|
You need the complete set of patches which is the list here: dotnet/installer#14549 (comment). All of these have been backported to 7.0 for the next release. And two PRs for installer which have not been backported yet to 7.0: dotnet/installer#14549 and dotnet/installer#14938. |
We need to make sure Microsoft.NETCore.App.deps.json has a complete runtime fallback graph. Otherwise, it is possible that .NET will fail to find assets placed in paths based on the RID-fallback graph. For more details, see dotnet/runtime#78563
|
It looks like the issue is not related to System.Data.Odbc and we can close the issue right? |
|
Yes we can close this issue |
Description
Support for ppc64le architecture was added in .NET7. Using this, we were trying some sample code which uses System.Data.Odbc package.
The sample code works on x86 machine with .NET7 but fails on ppc64le. We are not sure about the root cause of the problem but suspect it is because there is no enablement for ppc64le in https://github.com/dotnet/msbuild/blob/main/eng/common/cross
dotnet buildshows the MSBuild Version asMSBuild version 17.4.0+18d5aef85 for .NETThe .csproj has the following:
Project was created as follows:
Sample code ( note: we are able to connect to the database using cli )
But on Power ppc64le machine we are getting below error
During debugging what we found MSBuild::GetTargetPlatformIdentifier () may be returning empty string and this (https://github.com/dotnet/runtime/blob/main/src/libraries/System.Data.Odbc/src/System.Data.Odbc.csproj#L27) code throwing error. When we check the MSBuild repo https://github.com/dotnet/msbuild we don’t see ppc64le changes in eng/common/cross folder.
https://github.com/dotnet/msbuild/blob/main/eng/common/README.md says "The files in this directory are shared by all Arcade repos and managed by automation. If you need to make changes to these files, open an issue or submit a pull request to https://github.com/dotnet/arcade first." --
Question @akoeplinger :
Since the https://github.com/dotnet/arcade/tree/main/eng/common/cross has support for ppc64le, does it also need to get propagated to msbuild?
Note: We opened the same issue in the arcade repo ( see dotnet/arcade#11675 ) but since we don't know if our analysis of root cause is right, opening it in the runtime repo also
Tagging @omajid / @Sapana-Khemkar / @uweigand for awareness.
Reproduction Steps
On a ppc64le machine
Install .net7 SDK
Install mysql, created database and table, add sample data in table. Verify that you can connect to database and retrieve data using command line
Create a sample C# program that uses System.Data.Odbc to connect to the backend mysql database
dotnet runExpected behavior
Be able to connect to the database and retrieve data
Actual behavior
Regression?
No response
Known Workarounds
No response
Configuration
Other information
No response
The text was updated successfully, but these errors were encountered: