When using GNU ld or GNU dlltool, it is needed to mark ordinal-only export
with NONAME keyword. Otherwise the import library would use export by name,
instead of by ordinal.
Signed-off-by: Martin Storsjö <martin@martin.st>
This code block detected that the return value is from other library
function. It does not mean that function forwards to another one.
For example lot of times gendef detected that the call is GetLastError()
from kernel32.dll. But it does not mean that the function was forwarded to
GetLastError(). It just means that one of the code branch was propagating
return value from GetLastError().
Signed-off-by: Martin Storsjö <martin@martin.st>
gendef by default always scans current directory for other hint .def files
which are later parsed. This default behavior is sometimes problematic, so
add an option --no-include-current-dir which disables scanning of the
current directory for other hint .def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
Decorated I386 fastcall functions have symbols with "@NAME@SIZE" pattern.
Normally function symbols from libraries are exported undecorated, symbol
name matches the function name. But some libraries export I386 fastcall
functions with decorated symbol names.
For example msvcr80.dll library exports symbol "@_calloc_crt@8" for which
gendef without this change generates line "@_calloc_crt@8@8", which cannot
be easily used by applications. With this change it generates line
"@_calloc_crt@8 == @_calloc_crt@8" which allows applications to call
fastcall function _calloc_crt(void *ptr, size_t size).
Signed-off-by: Martin Storsjö <martin@martin.st>
Decorated I386 stdcall functions have symbols with "_NAME@SIZE" pattern.
Normally function symbols from libraries are exported undecorated, symbol
name matches the function name. But some libraries export I386 stdcall
functions with decorated symbol names.
For example msvcrt20.dll library exports symbol "__seh_longjmp_unwind@4"
and gendef without this change generated line "__seh_longjmp_unwind@4@4",
which cannot be easily used by applications. With this change it generates
line "_seh_longjmp_unwind@4 == __seh_longjmp_unwind@4" which allows
applications to call stdcall function _seh_longjmp_unwind(void *jmp).
Signed-off-by: Martin Storsjö <martin@martin.st>
binutils (objdump) accepts PE binaries (EXE/DLL) with zero value in
OptionalHeader's Magic field. Do same in gendef. Such I386 DLL binaries are
distributed as part of the Win32s.
Signed-off-by: Martin Storsjö <martin@martin.st>
By hardcoding the use of -Werror, we risk that the build can break
on any newer (or older) toolchain which can give warnings for
unexpected issues.
Fixing such issues is of course desired, but we shouldn't be breaking
the build universally, unless the user explicitly has asked for
this behaviour.
Signed-off-by: Martin Storsjö <martin@martin.st>
This tool isn't evolving particularly much at the moment, so the
additional value of knowing when a particular version was built
doesn't give much extra value.
Normally, a stripped build of gendef (on Linux) produces a binary
with the exact same hash each time. Using __DATE__ breaks that
reproducibility, if rebuilt on different days. It is possible to
avoid the issue by setting SOURCE_DATE_EPOCH to a fixed value when
building, but in this case, I think the printed date doesn't add much
value, so we could simply remove it. Most other similar tools don't
contain such printouts.
Signed-off-by: Martin Storsjö <martin@martin.st>
This tool was meant as a standalone replacement for dlltool,
for generating import libraries, but it never got feature parity
(in particular, it lacked support for generating symbol aliases,
which are cruicial for the core mingw-w64-crt import libraries).
The same author later created llvm-dlltool which fulfilled the
niche which genlib initially was meant to handle, effectively
orphaning genlib.
The last update to the source is in 2015, and no known third party
build configurations actually use this tool. (Although some might
be building the tool even if it isn't used; such builds will need
to be updated though.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Building genpeimg with clang v16 fails like:
error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
pe->is_64bit = 1;
is_64bit is always ever comapred against 0 in our case, so the value change
doesn't matter, but let's just make it unsigned to fix the error and avoid
any future confusion.
The same is theoretically true for is_bigendian, but that currently
never set to 1 in any place. Make it unsigned as well while at it.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
There are very few details about this tool. In addition, neither MSYS2
nor Debian includes this tool in their toolchains. I believe it should
be out of date and of no use, and may hence be removed.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Widl uses a subset of Wine headers, on top of the host's platform
headers (either Unix or Windows ones). When building widl for a
Windows target, the included Wine headers end up being preferred
over the toolchain's own platform headers.
Wine defines the __fastfail function in the winnt.h header (as
a static inline function), while mingw-w64 headers define it in
_mingw.h as a extern gnu_inline function.
When built with Clang, this combintion of an extern declaration
and static inline, ends up producing extern definitions of the
function in every compilation unit that ends up including both
headers - which ends up as linker errors due to duplicate definitions.
(GCC doesn't seem to produce any extern definitions in these cases.)
Patch the imported winnt.h from Wine, to skip the definition of
__fastfail if __MINGW_FASTFAIL_IMPL is defined (which is set by
_mingw.h).
Signed-off-by: Martin Storsjö <martin@martin.st>
