On Tue, 16 Apr 2024, LIU Hao wrote:
在 2024-04-16 05:19, Martin Storsjö 写道:
Hmm, I would prefer if you'd add a new macro for this purpose, instead of
reusing the old one.
The old existing one is used to add aliases for functions, usually like
this:
---
_somefunc
ADD_UNDERSCORE(somefunc)
---
But here, you're adding an alias as a way to specify the literal DLL import
name, as a way to undo the effect of dlltool's "-k" option for one single
symbol. So I see it semantically as a different thing, so a new macro, e.g.
"LITERAL_STDCALL(somefunc@4)" instead. Or maybe KEEP_STDCALL() or something
like that?
(The reason why I want to make the distinction, is both because I feel that
it's semantically a different thing, but also because llvm-dlltool doesn't
handle this exact case right now, it only works with the aliases in the
former style. But I think it should be possible to improve llvm-dlltool to
make this case work as well.)'
Yes, this is indeed abuse.
I can add a macro for MSVCR* DLLs, but, this patch includes a hunk for
'x3daudio1_2.def', which is consumed without `-DDEF_I386` etc. I have an
impression that 'lib32/*.def' should not use those macros.
We can either spell it out manually, like what we have currently in
x3daudio1_2.def (I guess the main bug there is that it should be
"X3DAudioCalculate@20 == _X3DAudioCalculate@20" without the leading "_" at
the start of the line?).
Or rename the file to .def.in; there's nothing saying that we can't use
.def file preprocessing for files in lib32, it's just that we haven't
really usually needed it so far.
And not only is 'x3daudio1_2.def', the only two functions which it exports
have changed to __cdecl, and require an incompatible header (which doesn't
exist however). Another option would be to just drop this file.
Yes, that bit seems like a big mess too.
I'm not at all familiar with these APIs and DLLs, so I don't quite know
what the best way forward is. But the fact that the same functions can be
declared with different calling conventions is indeed a bit of a problem.
If nobody really are using the files, it's probably ok to just remove
them, or remove the symbols and leave comments explaining the sitaution.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
