On 28/07/2015 00:29, Greg Beam wrote: > Hi BIll, Hi Greg, > > FWIW: > > * Installed Qt5.5 w/Tools (Mingw4.9.2) in: C:\JTSDK\qt55 > * Updated the JTSDK ENV, Build Script and ToolChain File(s) accordingly > * Ran the wsjtx-devel v1.6.0 Release Install Target build without > fatal errors. OK. The fixup problem is not a fatal error, it just silently fails to put some of the DLLs into the install area.
I have a fix but still need to prepare it for submission to the CMake developers. The underlying issue is that the Microsoft dumpbin utility crashes when processing executables generated by the latest GNU toolchains, this is unfortunate since they are perfectly acceptable to Windows and the commonly used tool depends.exe has no problem parsing them :( The result is that MinGW objdump has to be used to process the executables to find dependencies and this is horrendously slow in CMake. My patch will speed up processing with objdump as the parsing tool by orders of magnitude. > * On note on the Qt55 install, there doesn't' seem to be an > accessibility folder under plugins like there was in v5.2. That plugin no longer exists, I assume the accessibility functionality is now in the QtWidgets DLL on Windows, this makes sense since application authors will not have to know to ship the plugin. There is also a new plugin for audio on Windows, the current CMake should be picking that up. > * There were / are several warnings, but it's hard to tell if there > are any *new* ones that are not in the Qt5.2 build. > * libquadmath-0.dll landed in the install/bin directory, as did most > all the other DLLs that are normally there. OK, from that I can only assume you have not got dumpbin in the PATH and your CMake is using objdump. This surprises me as Release configuration install target builds will take ages with the install fixup using objdump! > > When running wsjtx.exe, I hit an entry point error right at start-up. > (see attached image). Until I get past that, I really cant tell if > there's other issues. If you need any of the build files let me know > and I'll send them over to you. That looks like a DLL version mismatch, are you sure that the install fixup worked? Old 5.2 Qt libraries in the install bin directory could cause that error. Try checking the version number in the file properties for QtCore.dll in the installed bin directory. > > I'll do some more build testing, and ensure all the source and build > DIR's are removed beforehand, including Hamlib3. That sounds like a good idea. > > Here's the App Summary: > C++ ........: 4.9.2 > GFortran ...: 4.9.2 > GNU Make ...: 4.1 > Cmake ......: 3.0.2 > Cpack ......: 3.0.2 > QT5 ........: 5.5.0 > Pkg-Cfg ....: 0.28 > > 73's > Greg, KI7MT > 73 Bill G4WJS. > On 7/27/2015 1:11 PM, Bill Somerville wrote: >> On 27/07/2015 19:50, Greg Beam wrote: >>> Hi Bill, >> Hi Greg, >>> Ubuntu Wiliy ( 15.10 ), if things remain as is, will be released with >>> Qt5.4.2. Ubuntu 16.04 may have Qt5.5 but that's only a guess at this >>> point. It all depends on the freeze points and possibly the import >>> source from Debian. >>> >>> For Debian, the experimental branch is the only one using Qt5.5 at the >>> moment. Jessie is 5.3.2, Stretch is 5.4.2, Sid is 5.4.2. It could be a >>> good while before Debian see's Qt5.5. >> Understood. The changes should be backwards compatible so I do not >> expect problems for those still using older versions of Qt and tools. >>> I suppose we could do some testing on Windows, but what about the tools >>> chain? I'm assuming we'd need 4.9 or maybe even the 5.x series >>> compilers >>> ( or whatever Qt5.5 was built with ). I've not even looked at the >>> OpenSource Installer to see what v5.5 was / is built with. >> MinGW-32 4.9.1 for v5.4 and MinGW-32 4.9.2 for v5.5. As always, the >> tools provided with the Windows Qt install must be used to build WSJT-X >> and Hamlib. >> >> I already seem to have run into an issue with building Release >> configuration installs on Windows with Qt 5.5. This is an issue I hit >> before when trying out Qt 5.4 and it still seems to be there with 5.5. >> The issue is that the dependency walker that the install fix up uses >> does not detect that libquadmath is required by libgfortran so it does >> not get added to the install location. I am not yet able to tell if it >> is a CMake issue, a tool chain issue or, a Fortran library issue. >>> 73's >>> Greg, KI7MT >> 73 >> Bill >> G4WJS. >>> >>> On 7/27/2015 12:16 PM, Bill Somerville wrote: >>>> Hi All, >>>> >>>> I have updated the sources to work with Qt v5.5. The changes were >>>> trivial but I would appreciate any reports of other issues from anyone >>>> building with Qt 5.5 on any platform. >>>> >>>> I will start working through my production VMs upgrading to Qt 5.5 but >>>> that will take a while. >>>> >>>> 73 >>>> Bill >>>> G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
