On 05/10/2018 02:37 PM, Richard Kimberly Heck wrote: > On 05/10/2018 11:41 AM, Kornel Benko wrote: >> Am Mittwoch, 9. Mai 2018 11:59:01 CEST schrieb Richard Kimberly Heck >> <rikih...@lyx.org>: >>> On 05/09/2018 11:18 AM, Pavel Sanda wrote: >>>> Jürgen Spitzmüller wrote: >>>>> 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: >>>>> >>>>>> I'm intending to close stable to string changes shortly, so we can move >>>>>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs >>>>>> doing before we notify the translators? >>>>>> >>>>> Any plans how to proceed with the Windows binaries? >>>> If Uwe definitively decided that no compromise is possible (I haven't seen >>>> such >>>> final announcement yet though) and intends to fork the installer to github >>>> we >>>> could simply state on the web that due to lack of manpower we do not offer >>>> official win installer any more and invite potential contributors to pick >>>> up >>>> the code & rebuild it. Sooner or later someone will pop up. >>>> >>>> If that sounds too harsh we could abandon the installer for the moment and >>>> publish just lyx binaries/lyx tree in zip archive and let interested users >>>> install the rest of the chain. That would take some initial effort but once >>>> done, should be easy to maintain for the subsequent stable releases. >>> I am working on this. I've managed to compile for Windows using mingw on >>> Linux (amazingly easy, actually) but have not dealt with the packaging >>> issues yet. Fortunately, someone who reported a bug to us seems as if >>> they may have done so and is giving me some help. >>> >>> Riki >>> >> Did you use cmake? (That is the script development/cmake/scripts/xmingw) >> If so, there should be created 'LyX24-2.4.0-win32.zip'. >> All needed files are also created in the directory 'LYX_INSTALLED' > No, I did not know about that. I just used the mingw-configure script > for autotools. I'll try the cmake version.
This almost works now. I had to modify the xmingw script a bit, and I ran into a few other issues that I was able to solve. But now I'm stuck. At the very end, I get: /usr/bin/i686-w64-mingw32-g++ -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing -O2 -DNDEBUG -Wl,--whole-arceFiles/LyX.dir/objects.a -Wl,--no-whole-archive -o ../bin/LyX.exe -Wl,--out-implib,../bin/libLyX.dll.a -Wl,--major-iman,0,--minor-image-version,0 @CMakeFiles/LyX.dir/linklibs.rsp ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text+0x15fd0): undefined reference to `_imp___ZN8QEv' ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text$_ZN3lyx8frontend20QWindowsMimeMetafileD1Ev[__ontend20QWindowsMimeMetafileD1Ev]+0x8): undefined reference to `_imp___ZN8QWinMimeD2Ev' ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text$_ZN3lyx8frontend20QWindowsMimeMetafileD0Ev[__ontend20QWindowsMimeMetafileD0Ev]+0xe): undefined reference to `_imp___ZN8QWinMimeD2Ev' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x72): undefined reference to `z_gzread' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x10c): undefined reference to `z_gzopen' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x182): undefined reference to `z_gzclose' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x28e): undefined reference to `z_gzwrite' collect2: error: ld returned 1 exit status One of the problems I had, actually, was that #include <QWinMime> was failing. I created symlinks to the right files, which I guess were in different directories from where they were expected to be. But now, it seems, the link is failing. I believe the wanted object is libQt5WinExtras.dll.a on this machine, and that is installed. The other problem seems to be with zlib. I've got libz.a and libz.dll.a in the appropriate place. This does work with the autotools build, so I've got the right things somewhere. Riki
