在 2023-05-05 03:59, Martin Storsjö 写道:
Wouldn't you need to use the -k option to dlltool here too, to make the stdcall-decorated symbols in
the import library point to undecorated names in the DLL?
Ah thanks, definitely, it was an oversight.
--
Best regards,
LIU Hao
OpenPGP_signature
Descr
Thank you all for intervening!
I have now opened https://sourceware.org/bugzilla/show_bug.cgi?id=30421.
Tomorrow I'll try applying some of the suggestions presented here
BR,
Luca
Il gio 4 mag 2023, 22:00 Martin Storsjö ha scritto:
> On Fri, 5 May 2023, LIU Hao wrote:
>
> > The 'proper' workaro
On Fri, 5 May 2023, LIU Hao wrote:
The 'proper' workaround for this (probable) bug is:
# First, create a DEF containing correctly decorated names. The DLL
# is unwanted and can be /dev/null.
gcc test.c -shared -O2 -o test.dll -Wl,--output-def,test.def
# Second, create a DLL containing
在 2023-05-05 01:53, Jeremy Drake via Mingw-w64-public 写道:
You might also be interested in the linker options
--add-stdcall-alias/--enable-stdcall-fixup, but I think those are just for
symbols exported by annotating with dllexport (or --export-all-symbols),
not for those explicitly exported from a
在 2023-05-04 22:50, Luca Bacci 写道:
It seems mingw-w64 gcc generates an import .lib that provides *undecorated*
names. That's not the case with clang or cl.
This looks like an LD bug and should be reported [1].
For the time being, there are some workarounds, so I would like to know whether it i
Hi again,
> > Yes, but that is an ABI change, on what is supposed to be a
> > standardized interface. They can't just break all existing callers
> > who expect the calling convention to be stdcall.
> >
> > I think the only way is to have separate def files for x86 and
> > everything else. Does G
Hello, Jeremy!
> Does GetProcAddress not deal with stdcall-decorated exports transparently
on x86?
No, unfortunately. That's also explained by Raymond Chen in two blog posts:
- https://devblogs.microsoft.com/oldnewthing/20040112-00/?p=41083
- https://devblogs.microsoft.com/oldnewthing/2006
I could do that for my projects, however we're encountering the issue
while building upstream Khronos projects in MSYS2:
- https://github.com/KhronosGroup/Vulkan-Loader
- https://github.com/KhronosGroup/OpenCL-ICD-Loader
Khronos defaults to using undecorated names and __stdcall calling
con
On Thu, 4 May 2023, Kacvinsky, Tom wrote:
> I cloned the repo and built with mingw-w64 x86, but used __cdecl instead of
> __stdcall. The import library had the right name decoration for x86 (x64 does
> not have a leading underscore), but the DLL had the symbol exported exactly
> as was specified
Hi again,
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Thursday, May 4, 2023 12:45 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: RE: [Mingw-w64-public] Exported symbols of import .lib are
> influenced by the .def file
>
> Hi Luca,
>
> > -Original Message-
> >
Hi Luca,
> -Original Message-
> From: Luca Bacci
> Sent: Thursday, May 4, 2023 11:38 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Exported symbols of import .lib are
> influenced by the .def file
>
> Thanks for the response, Tom!
>
> Yes, that would
Thanks for the response, Tom!
Yes, that would work, but we'd end up with decorated names in the export
table fo the DLL. For some projects that's a problem, because there's no
uniform way to call GetProcAddress.
Luca
Il gio 4 mag 2023, 17:32 Kacvinsky, Tom ha
scritto:
>
>
> > -Original Mes
> -Original Message-
> From: Luca Bacci
> Sent: Thursday, May 4, 2023 10:50 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Exported symbols of import .lib are influenced
> by the .def file
>
> Hello! we're observing a problem when compiling x86 DLLs using
Hello! we're observing a problem when compiling x86 DLLs using mingw-w64
gcc. Developers may choose to mark exported functions of a DLL using a .def
definition file:
LIBRARY mylib.dll
EXPORTS
foo
bar
Most of the times a .def file is used to export *undecorated* symbols from
a DLL, so that use
14 matches
Mail list logo
