[cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

Devs,

It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but
as reported on the CMake users mailing list, it can be a problem when the
directory cmake-gui is in is on the PATH. If CMake's bin directory appears
on the PATH, the Qt DLL's bundled with it can take precedence over other
applications' own Qt DLLs. The cmake and ccmake executables have a
reasonable case for being on the PATH, but cmake-gui is typically going to
be started via a desktop or menu icon and doesn't really need to be on the
PATH.

Rather than forcing static Qt libs to be used (I'm not aware of the reason
for the change from static to dynamic Qt libs), we could instead move
cmake-gui out of the bin directory so that it isn't in the same directory
as the cmake and ccmake executables. This top level directory should never
be added to the PATH, so it would resolve problems like the above. It is
not unusual for the main executable to be in the top level directory of an
installation rather than in a bin subdirectory. What do people think of
moving cmake-gui and the Qt DLL's up to the top level? This may just be for
Windows, other platforms could stay as they are now. Would obviously have
to adjust not just the install location but also any internal code that
tries to work out where other files are located relative to the cmake-gui
executable. Things like the qt.conf file would also probably need some
adjustment.

Thoughts?


---------- Forwarded message ----------
From: Craig Scott <craig.scott at crascit.com>
Date: Mon, Aug 14, 2017 at 7:47 PM
Subject: Re: [CMake] cmake-gui on windows and qt5 dlls
To: Christian Ehrlicher <Ch.Ehrlicher at gmx.de>
Cc: CMake <cmake at cmake.org>


This is a common problem, not just with CMake. I'm wondering if there's any
real need for cmake-gui to be on the PATH at all, since it will usually be
invoked by a desktop or menu icon. At the moment though, it is in the same
directory as the cmake and ccmake executables which have a much stronger
case for being on the PATH. There's a reasonable argument that cmake-gui
should be in a different directory, then it wouldn't be an issue if shared
Qt libs were used rather than static. I'll bring this up on the developer
mailing list and see what discussions yield.


On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher <Ch.Ehrlicher at gmx.de>
wrote:

> Hi,
>
> I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems
> during my build because it looks like the pre-compile binaries for windows
> are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics).
> The problem is, that I had the path to cmake *before* the path to my own
> Qt5 libaries. So during the build / run of my application, the wrong
> libraries were loaded and I got a symbol lookup error.
> Would it be possible to use the static Qt5 libs instead or maybe prefix
> the Qt5 libs shipped with cmake-gui somehow?
>
> Thx,
> Christian
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170814/bfe479e2/attachment.html>