Pre-built KF5 archives and okular

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Jun 3 16:08:53 UTC 2016


Hi,

On Thu, 2 Jun 2016 12:00:17 +1000
Jonathan Schultz <jonathan at imatix.com> wrote:
> First of all, thank you so much Thomas for providing those archives. 
> Without them I'd probably still be struggling to build any KDE apps
> on Windows. Now I can build okular using mingw/x86 which is a great
> start.

I'm glad these are useful to you. I hope to provide some updates in a
few weeks, too, but rather busy, ATM.
 
> That said, I have a few comments and further questions. Your
> assistance with any of them would be most appreciated.
> 
> 1. The README says that the builds require at least Windows 8.1 
> Everything I describe below I have tried using both Windows 8.1 and 
> Windows 7, and have seen no difference at all between the two.

Good to know. I wasn't sure about binary compatibility on Windows, and
simply assumed a Win 8.1 build system would mean requiring a Win >= 8.1
runtime.

> 2. Of the archives, only the first one (KF5_emerge.7z) allows me to 
> build okular, and succeeds with no extra intervention. This tells me 
> that there is no big problem preventing okular from building.
> However, with the other archives I find that I'm getting some linking
> errors. Using KF5_emerge_MinGW4.9.2.7z the build fails on libcurl
> with the following output:
> 
> > K:/k/lib/libcrypto.a(bss_sock.o):bss_sock.c:(.text+0x90): undefined
> > reference to `_imp__shutdown at 8'
> > K:/k/lib/libcrypto.a(bss_sock.o):bss_sock.c:(.text+0x1c0):
> > undefined reference to `_imp__shutdown at 8'

Hm, I do remember running into this, and I have managed to build
libcurl, subsequently, but unfortunately, I do not rememeber, how I got
around it. For the record, my installed version of openssl is 1.0.2f
and of libcurl 7.46.0. Perhaps try those versions, first.

Will try to recover details, as time allows.

> And using the MSVC archive KF5_emerge_MsVS2013.7z it fails building 
> libspectre with the following:
> 
> > [ 75%] Linking C shared library spectre.dll
> >    Creating library spectre.lib and object spectre.exp
> > spectre-gs.c.obj : error LNK2019: unresolved external symbol
> > _gsapi_new_instance referenced in function
[...]

Cannot comment.

> 3. Finally I have also tried to replicate your build process (partly
> to prove to myself that I can do it, but also so that I can build a
> 64 bit version) and it fails with:
> 
> > In file included from
> > K:\k\download\git\qtbase\src\plugins\platforms\windows\qwindowsfontdatabase_ft.h:37:0,
> > from
> > K:\k\download\git\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp:45: ..\..\..\..\include\QtPlatformSupport\5.5.1/QtPlatformSupport/private/qbasicfontdatabase_p.h:1:124:
> > fatal
> > error: ../../../../../../../../../../download/git/qtbase/src/platformsupport/fontdatabases/basic/qbasicfontdatabase_p.h:
> > No such file or directory
> 
> What I notice here is that the file 
> .../QtPlatformSupport/private/qbasicfontdatabase_p.h is in different 
> locations in the different builds. In your three archives there is a 
> copy under k/include while when I try to build it is only under 
> k/build/libs/qtbase/work/mingw-w64-RelWithDebInfo-5.5/include There
> are some other differences too, which I can describe if that would
> help, but I'm hoping that in the meantime someone can tell me what
> might be going wrong.

Dirty secret: This was totally baffling to me. There are thousands of
headers like these, and a select handful fail for no apparent reason
(yes, there are several more to come). So I cheated on these: For each
of these errors , I edited the forwarding header
(K:\k\include\QtPlatformSupport\5.5.1/QtPlatformSupport/private/qbasicfontdatabase_p.h,
in this case) to point to the _absolute_ location of the real header
(K:k/download/git/qtbase/src/platformsupport/fontdatabases/basic/qbasicfontdatabase_p.h,
in this case). Hint: Use "emerge --compile qtbase" to restart
compilation, without reconfiguring.

All affected headers are private ones, so there are no "real"
consequences to fear, once you have cheated your way past this...

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20160603/3999121a/attachment.sig>


More information about the Kde-windows mailing list