Open Crono1981 opened 1 year ago
Another thing that might be of interest:
It is reported here that Linux runners on GitHub have SQLite v3.37.2 preinstalled.
I did not find anything about SQLite for MacOS runner.
I have no idea how / if that has any impact on what SQLitePCLRaw
does, though.
I think the last time I worked in that area of the code I broke certain cases involving Mono. Now that .NET Core (and its descendants) is mature and cross-platform, Mono is becoming an even less common case. That said, if you're using net481
with actual RuntimeIdentifiers
like linux-x64
, then I think SQLitePCLRaw should do the right thing.
Hi. We have the same issue. After GitHub Actions moved the ubuntu-latest
image tag from 20.04 to 22.04, some of our tests for Entity Framework Core that use SQLite during testing started failing. We multi-target to run those tests on net7.0;net6.0;netcoreapp3.1;net48
and matrix in GitHub Actions to run on Ubuntu, macOS, and Windows. Only the net48
target fails, and only on Ubuntu 22.04.
Switching to specifically use the ubuntu-20.04
GitHub Actions runner image appears to have mitigated the problem for now. I haven't investigated further. See https://github.com/getsentry/sentry-dotnet/pull/2083 for details.
@mattjohnsonpint Interesting. What changes does ubuntu 22.04 imply? For example, is it bringing in a different version of mono?
Nope. Same version of Mono, as far as I am aware. 6.12.0.182. It was rather surprising to me as well.
I'll investigate further when I can find some time.
I agree that the pre installed versions of SQLite should not matter.
Different versions of the dotnet SDK?
Shouldn't matter for tests that execute on Mono. The error happens at run time, not at build time. They are both using the latest .NET 7 SDK to run the tests.
My gut feeling is it's some lower-level native dependency that is the culprit.
The error happens at run time, but it could be due to a failure to copy the native library dependency into place during the build. In fact, that's my guess of what's going on here. There's an msbuild targets file that does this copying, and in the past its behavior has been affected by a lot of different build-related issues.
If that supposition is correct, a key difference is which shared libraries are getting copied into the build output.
@ericsink
but it could be due to a failure to copy the native library dependency into place during the build. In fact, that's my guess of what's going on here.
I did find the following file on the Ubuntu runner after building the code:
bin/Release/net481/runtimes/linux-x64/native/libe_sqlite3.so
Is it what you're talking about?
@Crono1981 Yes, but is that from the one that succeeded or failed?
And you might find build outputs in that form (in a runtimes directory, with a RID directory under that, etc). Or you might find libe_sqlite3.so in the top level of the output directory, and the latter case might depend on whether you are building with a RuntimeIdentifier
property or not.
I'm being vague here because your situation may be a part of a larger related issue, but I don't fully understand what's going on yet.
@ericsink the one that failed.
My gut feeling is it's some lower-level native dependency that is the culprit.
Maybe my e_sqlite3 builds are somehow incompatible with ubuntu 22.04. Like, for example, they are looking for the wrong libc, or something.
But if that were the case, why would it affect only net48
/Mono?
We need a more minimal repro.
I'm having the same issue with Framework 4.8.0 running on Raspberry Pi OS (32bit) (basically Debian), and mono 6.12.0.182.
dlopen TryLoad: /usr/share/CumulusMX/runtimes/linux-arm/native/libe_sqlite3.so
thrown: System.DllNotFoundException: dl assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) SQLitePCL.NativeLibrary+NativeLib_dlopen.dlopen(string,int)
at SQLitePCL.NativeLibrary.TryLoad (System.String name, SQLitePCL.NativeLibrary+Loader plat, System.Action`1[T] log, System.IntPtr& h) [0x00069] in <7ea8f9164048497c988e9906e742dabe>:0
dlopen TryLoad: /usr/share/CumulusMX/libe_sqlite3.so
thrown: System.DllNotFoundException: dl assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) SQLitePCL.NativeLibrary+NativeLib_dlopen.dlopen(string,int)
at SQLitePCL.NativeLibrary.TryLoad (System.String name, SQLitePCL.NativeLibrary+Loader plat, System.Action`1[T] log, System.IntPtr& h) [0x00069] in <7ea8f9164048497c988e9906e742dabe>:0
NOT FOUND
at SQLitePCL.NativeLibrary.Load (System.String libraryName, System.Reflection.Assembly assy, System.Int32 flags) [0x00058] in <7ea8f9164048497c988e9906e742dabe>:0
at SQLitePCL.Batteries_V2.MakeDynamic (System.String name, System.Int32 flags) [0x00010] in <7ea8f9164048497c988e9906e742dabe>:0
at SQLitePCL.Batteries_V2.DoDynamic_cdecl (System.String name, System.Int32 flags) [0x00000] in <7ea8f9164048497c988e9906e742dabe>:0
at SQLitePCL.Batteries_V2.Init () [0x00000] in <7ea8f9164048497c988e9906e742dabe>:0
The libe_sqlite3.so file is in the runtime folder it is searching.
Minimal test, also fails: https://github.com/mcrossley/SQLiteTest1 Using PCLraw v2.1.4
Prior to trying these packages, I just used the sqlite3.dll (x86 for Windows - download direct from www.sqlite.org), with the sqlite-net wrapper file SQLite.cs
This limited me to 32bit only which is what I wanted to get away from. But that Windows x86 DLL works fine on Raspberry Pi OS Linux when running under mono on an ARM processor.
2.1.2
bundle_green
Ubuntu Linux 22.04 on x64 processor. More specifically, it is a GitHub provided runner for GitHub Actions.
4.8.1
.NET Framework (mono)
I'm running
dotnet test
from the command line:In case you want to see it, here's the build command that was ran prior to the test command:
It's the first time I ever try building on Mono for Linux.
Here's the complete error output:
PackageReference
Not using mobile platform.
I don't have a repro sample project, but I can tell you this: project is a Xunit test project, with the following MSBuild properties:
I've also taken care of adding a
xunit.runner.json
file within the project's directory:I tried running the same commands on both Linux and MacOS runners in GitHub Actions. Much to my surprise, on the Mac runner, the whole thing works. It looks like there's something particular going on with Mono on Linux.
I did notice that on the Ubuntu runner the following output file was produced after build:
bin/Release/net481/runtimes/linux-x64/native/libe_sqlite3.so
On the Mac runner, I had this one instead:
bin/Release/net481/runtimes/osx-x64/native/libe_sqlite3.dylib
Judging from the message in the stack trace, I'm assuming that there's something wrong with
libe_sqlite3.so
when it is accessed from Mono on Linux, whereas itsdylib
counterpart works okay on Mono for Mac. 🤷♂️If I think of anything else, I'll comment below. In the meantime, if you have any pointers you can give me, that would be much appreciated.
Thanks for all your incredible efforts.