葡萄酒规格文件 [英] Wine spec files

问题描述

我有一个名为 morag.dll 的Windows DLL，其中包含函数foo和bar。我还有一个名为 morag.so 的Linux SO，其中包含foo和bar（每个平台上的相同参数）的Linux实现。我有一个Windows应用程序，该文件加载要在wine下运行的 morag.dll 。该应用程序本身运行良好，但是我需要在foo和bar之间创建映射，而我和我的应用程序期望在 morag.dll 中找到该映射，以在其中使用foo和bar morag.so 。

I have a Windows DLL called morag.dll containing functions foo and bar. I also have a Linux SO called morag.so containing the Linux implementations of foo and bar (same parameters on each platform). I have a Windows application that loads morag.dll that I want to run under wine. The application itself runs fine, however I need to create the mapping between foo and bar which are expected by my application to be found in morag.dll to instead use foo and bar in morag.so.

为此，我知道我需要创建 morag.dll .spec 文件并将winebuild到 morag.dll.so 。

To do this I know I need to create morag.dll.spec file and winebuild it into morag.dll.so.

按照说明进行操作在此我在 morag.c 包含函数 Proxyfoo 和 Proxybar ，这些函数仅调用真实函数foo和bar。然后我创建了 morag.dll.spec 这样：-

Following instructions here I created a wrapper in morag.c containing functions Proxyfoo and Proxybar which do nothing more than call real functions foo and bar. Then I created morag.dll.spec thus:-

1 stdcall foo (long ptr) Proxyfoo
2 stdcall bar (ptr ptr)  Proxybar

我编译了c部分，winebuild spec文件，然后使用winegcc将它们链接到 morag.dll.so

I compiled my c part, winebuild the spec file, and then use winegcc to link them into morag.dll.so

然后我阅读了此页面，这表明您可能不需要代理功能，因此我尝试了c部分，并因此制作了规格文件：-

Then I read this page which suggested you maybe didn't need the proxy function so I tried without the c part altogether and made a spec file thus:-

1 stdcall foo (long ptr)
2 stdcall bar (ptr ptr)

和上面一样，执行winebuild步骤和winegcc链接步骤。

And as above, did the winebuild step and the winegcc link step.

在这两种情况下，这些都是我使用的选项。

In both cases these were the options I used.

winebuild --dll -m32 -E ./morag.dll.spec -o morag.dll.o

ldopts= -m32 -fPIC -shared -L/usr/lib/wine -L/opt/morag/lib -lmorag

winegcc $(ldopts) -z muldefs -o morag.dll.so [morag.o] morag.dll.o

N.B。 [..]表示仅在构建c部分的情况下才使用此方法。

N.B. [..] denotes I only used this in the case where I was also building the c part.

在两种情况下，当我在wine下运行的应用程序尝试加载DLL使用 GetProcAddress 的入口点失败。

in both cases, when my application running under wine tries to load the entry point in the DLL using GetProcAddress it fails.

我用 WINEDEBUG = + module，+继电器，看到尝试和失败记录如下：-

I ran wine with WINEDEBUG=+module,+relay and saw the attempt and failure recorded as follows:-

0025:Ret  KERNEL32.LoadLibraryExA() retval=7dbc0000 ret=00447b84
0025:Call KERNEL32.GetProcAddress(7dbc0000,00b2d060 "foo") ret=00447c8a
0025:Ret  KERNEL32.GetProcAddress() retval=00000000 ret=00447c8a

似乎已经找到并加载了我的 morag.dll.so ，因为 LoadLibraryExA 返回了它的句柄，但是当它试图在该HMODULE句柄中查找函数foo时，它就会失败。

It seems it has found and loaded my morag.dll.so since LoadLibraryExA has returned the handle to it, but when it tries to find function foo within that HMODULE handle it fails.

如果我发出：-

nm -D morag.dll.so

在这两种情况下，我都看到foo和bar显示为U。在存在代理功能的情况下，代理功能也显示为T。

I see foo and bar shown as U in both cases. In the case where there are proxy functions as well, the proxy functions are shown as T.

我认为这是因为我尚未构建 morag.dll.so 文件正确，或者选项错误，或者我的规范文件格式不正确。我不确定应该使用上述两种方案中的哪一种。

I assume that this is because I have not built the morag.dll.so file correctly, either with the wrong options, or that my spec file is not correctly formed. I am not sure which of the two schemes described above I should be using.

最能得到所有帮助。

推荐答案

我今天也遇到了同样的问题。

I ran into the same problem today.

我的案子所缺少的是正确的导出规则，例如内置DLL中的 foo 和 bar 。方便地，除了-dll 对象之外， winebuild 工具还可以为我们创建一个.def文件，例如：

What was missing in my case was the proper exporting rule for e.g. foo and bar in the built-in DLL. Conveniently, besides the --dll object, the winebuild tool can create a .def file for us, e.g.:

morag.def: morag.spec
    $(WINEBUILD) --def -E $< -o $@

生成的.def文件必须与其他文件链接到morag.dll.so中对象。这样就可以了。

The resulting .def file must be linked into morag.dll.so along with other objects. This does the job.

这篇关于葡萄酒规格文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！