How to link external symbols at runtime in windows?

help
1

Based on this wiki: nvim-oxi/examples at main · noib3/nvim-oxi (github.com)

The way to do it for macos it the following:

image
image1051×331 12.4 KB

Using those same options does not seem to work on windows, refer to this issue for details about the errors on windows [Windows][Powershell7] linking with link.exe failed: exit code: 1120 · Issue #120 · noib3/nvim-oxi (github.com), but in short, I conclude based on the answer in this other thread Cdylib cannot resolve symbols - #8 by bjorn3 that there are different ways to do it for each platform. So, can someone help me figure out what would be the right way to do it when using windows (powershell-7) ?

Many Thanks

2

So, I don't know about what special requirements nvim might have, if any, but why do you want to only resolve the symbols at runtime? Dynamic libraries are already linked at runtime, it's just that on Windows you need an import library to actually tell the linker "hey, you need to look in (something.dll) to find this symbol".

It sounds a bit like you're trying to link against a library without the import lib and... that just doesn't work on Windows. The loader needs to know which library a symbol comes from, you can't (insofar as I'm aware) tell it to guess.

The symbols look like they're from lua/luajit. You'd want to look at (I assume) nvim and how it's structured to figure out the specific library you need to link against, and where to get its import library from.

(There are also ways to generate import libs, but that tends to depend on exactly how the DLL was made, and how the symbols were mangled, etc.)

3

so it works on linux and Mac, but just not on windows ?

4

Help please :frowning:

5

Please answer this:

1 Like
6

I understand that is a requirement so that it links with the luajit instance of neovim, when it gets executed, this is using the FFI feature. Basically with nvim-oxi we are supposed to be able to write neovim plugins using Rust

7

The Windows port may have a different approach. Some things change when porting software between different OSes.

e.g. I wouldn't be surprised if the Windows port built most of neovim's sources into a DLL to make it possible for plugin DLLs to import its symbols.

8

@DanielKeep @tbfleming so how can I import the required DLLs ? Assuming I already have them

9

So on both Windows and every other platform, you traditionally have the distribution libraries and, separately, the development libraries. The former contains the .dll / .so files, probably config files etc, while the latter contains C header files and libraries, .lib / .a that could be static libraries containing code, or link libraries containing import data used to tell the os how to load the actual code at runtime (the linker itself doesn't care, it's just copying bytes into sections and linking up addresses: in both cases the library tells it where to link references to the imported symbol so it's happy)

If you for some reason don't have a development library for some dll, you could try creating the import library for it manually, using lib.exe /def:foo.def: https://learn.microsoft.com/en-nz/cpp/build/reference/module-definition-dot-def-files:

LIBRARY foo
EXPORTS
  some_symbol
  ...

But honestly there can be a lot of fiddling to get it correct and it really shouldn't be your problem as these import libraries are automatically created as part of the link of the dll already.

The normal way to load plugins like it seems this is doing is to call the OS APIs to load the library and lookup the symbol dynamically: libloading — Rust OS-specific library // Lib.rs is a wrapper that's commonly used in Rust for this.

1 Like
10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.