[Mingw-w64-public] DLL symbol decorations & gendef tool not distributed anymore

[Martin Mitáš]

Hello.

In the mCtrl project [1], we build a DLL. The aim is to have
the DLL without the typical symbol suffix decorations (@num).
This is to allow easy use of those symbols with LoadLibrary().

With mingw-w64, when linking against such DLL, the import lib
still needs to provide the decorations as ld tries to find
only decorated symbols.

Unfortunately, AFAIK, the GNU linker has only the option
-Wl,--kill-at. When not used, both the DLL and the generated
import lib have those decorations, making the DLL unfriendly
to LoadLibrary().

When used, none of those have those decorations, making the
import lib unusable with the linker which has created it.
That raises question whether it is really the intended behavior
or bug of that option.

With mingw-w64, I worked around by regenerating the import lib
with gendef and dlltool [2].

But with recent mingw-w64 builds, the gendef is no longer
distributed, making it an etxra pain for e.g. new people.

Is there better way, how to achieve the goal without manual
maintaining of two .def files? (The decorations differ in 32
and 64 bit builds.)

Or can gendef be re-added into future mingw-build releases?

[1]: https://gitgub.com/mity/mctrl
[2]: https://github.com/mity/mctrl/blob/master/mctrl/CMakeLists.txt#L69


Martin

[niXman]

Post by Martin Mitáš
Hello.

Hi,

...

Post by Martin Mitáš
Or can gendef be re-added into future mingw-build releases?

Yes, I will rebuild gcc-7.1 builds in the next weekend.

[LRN]

Post by Martin Mitáš
The aim is to have
Is there better way, how to achieve the goal without manual
maintaining of two .def files?

Um...don't use stdcall? IIRC, the @X decorations only apply to stdcall functions.

[Martin Mitáš]

Well, given the purpose of mCtrl project, it's often seen
as an extension of USER32.DLL and COMCTL32.DLL and as such
it is better to follow their conventions. That includes
stdcall and no decorations.

Furthermore, in the past I was told from several sides that
DLL can be used from some other languages on Windows iff
the exported functions are stdcall.

As far as I can remember, that included Delphi, VisualBasic
and some other languages (often those made by MS).

And, last but not least, such change at this point would mean
quite nasty break of DLL's binary compatibility.

M.

Post by Martin Mitáš
The aim is to have
Is there better way, how to achieve the goal without manual
maintaining of two .def files?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public