LibNode Discovery #425
LibNode Discovery #425
Conversation
…ocedures for locating the libnode library is done.
a) On Core+ platforms, NativeLibrary is used directly with a relative path off of the assembly. This causes a search across the applications .deps.json. This is the ideal scenario as long as the LibNode packages deliver the library into runtimes/{rid}/native.
b) On Framework platforms a search procedure is used. First, libnode is attempted to be loaded by relative name directly. This handles the situation where the library is directly available in some way. Such as relative to the executable. Second runtimes/{rid}/native is examined with a known RID based on current platform.
A few local NativeLibrary methods were improved.
Load was updated to support non-Windows platforms. This handles the scenario of Framework on ~Windows. Such as Mono.
TryLoad was introduced to probe paths during discovery.
GetExport/TryGetExport was updated to support non-Windows platforms. This handles the scenario of Framework on ~Windows. Such as Mono.
dlerror() was introduced to handle the situation of null exports. Which should not reaaaaly happen in libnode. But is technically correct.
The pinvokes to libdl are technically out of date. dl was merged into libc on Linux. And was already present in libc on OS X. But these are left.
I made changes to NuGet.config, removing the react stuff and the disabled sources. I don't know what the goal was here, but this was required to get the code building for me.
Expects to use Microsoft.JavaScript.LibNode version that deposit native libraries properly.
Change tests to not need a hard coded libnode path.
Remove LibNodePath parameter and replace with property on settings. Fix dlerror check. Should be zero.
…sed by the runtime's version of NativeLibrary.
…'t matter but might in the future.
…is that anything that has dl.so.2 as the proper library should have moved it to libc anyways. So I'm not sure what OS this actually applies to, but maybe there is something.
…al CLR version at which NativeLibrary appeared (future proofs change in compatibility).
|
@wasabii , the code formatter fails the PR validation. You can run the following script to fix some of the issues automatically. |
That command just runs a bit then throws an exception. Unhandled exception: System.Exception: source text did not have an identifiable encoding Anyway to identify the failures from the verification stuff above? Don't really see any.... |
I wonder if it is related to Windows platform somehow. Last time I did not see any issues. Edit: |
|
I just read your edit. Hehe. Gotcha. |
I see the same behavior on Windows. Anyway, the CodeQL is passing. I will play with other issues. |
|
The 9.0.2 throws the same exception as you reported above. |
|
This commit has all the required formatting issues: vmoroz@8587002 To fix the issue I had to switch the encoding of the files to CRLF for the formatter to run. |
|
I pulled that commit in. |
|
@wasabii , @jasongin , it seems I screwed up the NuGet release. |
Resubmitting a PR I did directly against @vmoroz's local fork earlier. As we talked about over there, right now, this PR has the LibNode packages pointing to my local fork, where the runtimes/{rid}/native directory is populated correctly. The PR thus is not ready to be accepted until the upstream LibNode packages are fixed up. But getting the discovery code visible I thought would be beneficial.
Allow null to be passed as libpath. The result is that a series of procedures for locating the libnode library is done.
a) On Core+ platforms, NativeLibrary is used directly with a relative path off of the assembly. This causes a search across the applications .deps.json. This is the ideal scenario as long as the LibNode packages deliver the library into runtimes/{rid}/native.
b) On Framework platforms a search procedure is used. First, libnode is attempted to be loaded by relative name directly. This handles the situation where the library is directly available in some way. Such as relative to the executable. Second runtimes/{rid}/native is examined with a known RID based on current platform.
A few local NativeLibrary methods were improved.
Change tests to not need a hard coded libnode path.