Don't run dlltool --output-exp to create a separate object file with
just export data (.edata section). In the case where at least one
function in the objects being linked has been explicitly marked for
export, GNU ld will not look for export information in the object
files anyway. At least the GetVersion() function seems to be marked
for export explicitly. Just pass the .def file when linking.
GNU ld since 2.17 supports @cmdfile syntax, just like MSVC tools, so
no need to create a separate shell command file and source that. (Why
that even would work better than just running the ld command with a
long command line directly, I don't know.)
Actually I don't know why even bother with the @cmdfile, after all we
mainly intend WNTGCC to be used when cross-compiling, and there are no
short command-line length restrictions on modern OSes from which one
might want to cross-compile. But oh well.
Pass the necessary -L switches, i.e. SOLARLIB, when linking with GNU
ld. (For MSVC, the ILIB environment variable is used.)
Produce the import library when linking, no need to have a separate
rule to produce an import library for WNTGCC.
Re-unroll tg_shl.mk into _tg_shl.mk with the recently unbroken
mkunroll tool.
Actually NSIS_PATH is crack, it is actually the *directory* where the
makensis program is located, so why not simply just have a variable
with the full pathname to that instead (or just the command name, in
case it is in the default PATH anyway, like on openSUSE with
/usr/bin/makensis)? That would simplify the stuff in download.pm, too.
* also change GNUMakefile.mk to find the RepositoryModule_*.mk, instead of Module_*.mk
* subsequenttests was broken by the introduction of tail_build, because there where two Module_*.mk in root
* addendum to commit 99079f03d95d525e7e95a56569c37094618fb2ca
Re-introduce the old --with-mingw option but now called
--with-mingw-cross-compiler. Its purpose is now specifically to give
the cross-compiler used when building the ODK, if Java is enabled, and
if building the unowinreg.dll. It has now nothing to do with
cross-compiling LibreOffice itself.
Correspondingly, the WITH_MINGW variable now has meaning only when
building LibreOffice for Windows: If using MinGW, whether natively on
Windows itself (which we as such don't intend to support, I hope), or
cross-compiling, it is set to "yes".
Automate and simplify the search for the MinGW cross-compiler when
intending to build unowinreg.dll on Unix.
Look for the usual tool-chain tools ar, nm, objdump, pkg-config,
ranlib, strip, and for Windows alto dlltool and windres using
AC_CHECK_TOOL so that the proper cross tools are found when
needed. Propagate to environment. As such these are not used except in
the MinGW mk files so far.
Other minor cleanups.
* also change GNUMakefile.mk to find the RepositoryModule_*.mk, instead of Module_*.mk
* subsequenttests was broken by the introduction of tail_build, because there where two Module_*.mk in root
