Some progress. Now the Qt project is generated

>> by dropping the PUBLIC keyword from the target_link_libraries command

I did

at line 318 of src/CMakeLists.txt I removed both the PUBLIC and PRIVATE 
words and added some messages like this


the ouput falls on the second case (else(NON_TRANSITIVE))

-- else NON_TRANSITIVE:         OFF

there are still 2 issues

1) Building the Visual Studio project, I get

========== Build: 16 succeeded, 72 failed, 0 up-to-date, 0 skipped 

basically all the examples failed with link errors of the kind

------ Build started: Project: x13c, Configuration: Debug Win32 ------
  Building Custom Rule M:/plplot-plplot/examples/c/CMakeLists.txt
  CMake does not need to re-run because 
M:\plplot-plplot\build\examples\c\CMakeFiles\generate.stamp is up-to-date.
     Creating library M:/plplot-plplot/build/examples/c/Debug/x13c.lib and 
object M:/plplot-plplot/build/examples/c/Debug/x13c.exp

Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
_hb_ot_tags_from_script referenced in function "public: bool __thiscall 
QFontEngine::supportsScript(enum QChar::Script)const "

But this might be because of the way I build Qt , so I'll try to debug this

But regardelss of this, the examples should not be attempting to link with 
the Qt libraries,

for example, the list of libraries for the x13c project is

Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\Gdi32.Lib;C:\Program Files 

2) the other issue is that the WxWidgets driver is not detected

Some time ago, I fixed that issue on the PLPlot version that was last 
released (not the git one) and posted here on this list the fix

but now with the git version,  is failing again, I'll go back and see what 
were the changes I made (adding the wxWidgets string corresponding to the 
latest "3.1.0" version
in some places)


----- Original Message ----- 
From: "Alan W. Irwin" <>
To: "Pedro Vicente" <>
Cc: "Hazen Babcock" <>; "PLplot development list" 
Sent: Sunday, October 16, 2016 2:17 PM
Subject: Re: [Plplot-devel] cmake error Qt build

> Hi Pedro:
> On 2016-10-15 21:07-0400 Pedro Vicente wrote:
>> Hi Alan
>> Thank you for your effort in debuging this.
>> I send some results here attached , and I'll keep trying other options 
>> later.
>> by the way, wxWidgets is also not detected.
>> I wonder, could this be a Windows only issue? Because you are trying on 
>> Linux, correct?
> Yes, all my tests are on Linux. Our goal is to tune our CMake-based
> build system so the Windows PLplot experience as just as smooth as on
> Linux, but we are not there yet, and your help in reporting any issues
> you find is important for helping us to reach that goal.  It turns out
> in this case, that the find Qt5 part of the issue is working smoothly
> on Windows.  That is, both your QTDIR and alternative
> CMAKE_PREFIX_PATH ways of setting up cmake appear to be giving you
> good Qt5_library_fullpath_list, etc., results.
>> also here
>> they specificaly say to *not* use the form
>> find_package(Qt5
>> but that is a resource from 2012, not sure if that is valid
> That resource is no longer valid.  Methods of finding Qt5 have been in a 
> big state of flux
> since those dark ages.
> [...]
>> first, the Qt location is detected
>> -- Qt5_library_fullpath_list = 
>> I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
>> -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Guid.lib 
>> I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
> Those good results imply you are finding Qt5 successfully on your
> system (and see my comments above about that).  The remaining issues
> you have discovered are general Qt5 issues rather than Windows only.
>> but then the errors are
>> CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
>> The plain signature for target_link_libraries has already been used with
>> the target "plplot".  All uses of target_link_libraries with a target 
>> must
>> be either all-keyword or all-plain.
> So after that Qt5 find succeeded, you ran into the same mixed
> plain/keyword target_link_libraries message you got before, and you
> have to locally fix that issue just like you did before by dropping
> the PUBLIC keyword from the target_link_libraries command indicated
> above.  The reason you are running into this is you are choosing to
> use static libraries, and if I did the same thing on Linux, I would
> also have to use that local workaround.  Once I get our build system
> changed so that it uses the modern Qt5 setup method, then I plan to
> comprehensively test both the shared (with and without dynamic
> devices) and static cases to confirm plain/keyword local workarounds
> are no longer necessary for any of the principal PLplot build
> configurations.
> Once you try the above local workaround, the important question is
> whether you still have the version inconsistency trouble that occurred
> for you before or whether the minimum version bump in the commit I did
> yesterday fixes that issue.  (And if it doesn't fix it, please bump
> the minimum version "5.3.1" that appears on line 80 of
> cmake/modules/qt.cmake to a minimum version that is consistent with
> your Qt5 version to see if that locally fixes the issue.)
> Alan
> __________________________
> Alan W. Irwin
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (; the Time
> Ephemerides project (; PLplot scientific plotting
> software package (; the libLASi project
> (; the Loads of Linux Links project (;
> and the Linux Brochure Project (
> __________________________
> Linux-powered Science
> __________________________

Check out the vibrant tech community on one of the world's most 
engaging tech sites,!
Plplot-devel mailing list

Reply via email to