On 2014-09-23 11:13+0100 Phil Rosenberg wrote:
> Hi Alan I found the problem. On Windows LoadLibrary is a macro. If _UNICODE
> is defined it is an alias for LoadLibraryW which requires a wide character
> string in utf16 encoding. Otherwise it is an alias for LoadLibraryA which
> requires a char string witch ascii encoding. This same method is used for all
> system calls which require a string.
> In my case, I have _UNICODE defined, but we always pass an ascii string so
> the name gets mangled by the different encoding.
> I have changed the code to call LoadLibraryA directly.
Hi Phil:
Does that change mean (or could you check if you haven't done so) you no
longer have to use the -DTEST_DYNDRIVERS=OFF workaround? Note, that
test should include dynamic devices with external dependencies (such
as qt or cairo) because it was only for those kind of devices that the
workaround was required in the past.
If true, that would mean you had solved a small but difficult
development mystery that had been plaguing Windows users for many years
which would be wonderful news indeed.
> [...] And now with that fixed - going back to the original issue for
this thread. All your changes re spaces in the path seem to work for
my setup, both for dynamic and static Libs. The ntk driver appears to
be functioning as it should. Note I am still using cmake 3 as I am
nervous about having two versions side by side - I really don't want
to break it.
That is good news indeed. However, could you respond to my comments
and questions below concerning the shared library case?
In sum, the point of collecting the device driver dll's and the dll
parts of shared libraries into the dll subdirectory is to make it easy
to change your PATH on Windows to that one location to get everything
you need to do build-tree testing. We are currently using a
long-deprecated CMake variable LIBRARY_OUTPUT_PATH to force that
desired result. I am interested in your reply to my question of
whether or not you got that desired result with LIBRARY_OUTPUT_PATH.
But regardless of that answer, I would like you to try the requested
experiments with dropping LIBRARY_OUTPUT_PATH and setting
CMAKE_RUNTIME_OUTPUT_DIRECTORY (or the combination of
CMAKE_RUNTIME_OUTPUT_DIRECTORY and CMAKE_LIBRARY_OUTPUT_DIRECTORY)
instead. If setting one (the preferred solution) or both of those
variables works, then please commit that result because I urgently
want to drop using the deprecated LIBRARY_OUTPUT_PATH.
Alan
> -----Original Message-----
> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> Sent: 23/09/2014 02:58
> To: "Phil Rosenberg" <philip_rosenb...@yahoo.com>
> Cc: "PLplot development list" <Plplot-devel@lists.sourceforge.net>
> Subject: RE: [Plplot-devel] tcl build problem
>
> On 2014-09-22 22:58+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>
>> [...]I have located the DLLs on the
> lib directory and added their directory to my path, but still they
> don't seem to be loading.
>
> Hi Phil (taking this conversation back to the list):
>
> You need access to all the dll's in the build tree, not just a subset
> of them.
>
> Your words above imply dll's are _not_ being automatically located by
> your CMake generator in the dll subdirectory of the build tree. This
> has never happened before with Windows platforms that I am aware of,
> and ignoring our setting of the LIBRARY_OUTPUT_PATH variable could be
> an issue with either your visual studio generator or else CMake-3.x
> itself (remember our build system is currently not debugged throughly
> for that version compared to all the testing it has received for
> CMake-2.8.x).
>
> We set LIBRARY_OUTPUT_PATH using the
>
> set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> command in the top-level CMakeLists.txt file just for the Windows
> case. That variable is an extreme example of a legacy variable
> (probably going back to CMake-2.0), and if it doesn't work for either
> of the two above situations, I am sure the advice we will be given by
> CMake devels is to use the modern counterparts of that variable
> instead which are some combination of setting the variables
> CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, and/or
> CMAKE_RUNTIME_OUTPUT_DIRECTORY.
>
> Here is the relevant background documentation (which you
> can find yourself by running "cmake --help-full") for those
> modern counterparts for those three different variables.
>
> "There are three kinds of target files that may be built: archive,
> library, and runtime. Executables are always treated as runtime
> targets. Static libraries are always treated as archive targets.
> Module libraries are always treated as library targets. For
> non-DLL platforms shared libraries are treated as library
> targets. For DLL platforms the DLL part of a shared library is
> treated as a runtime target and the corresponding import library
> is treated as an archive target. All Windows-based systems
> including Cygwin are DLL platforms."
>
> So on Cygwin or Windows it looks like shared library dll's (created
> for all our shared libraries) are treated as a "runtime" target and
> our device driver dll's (built as MODULE libraries) are treated as a
> "library" target. (That last makes no sense to me. Why wouldn't
> MODULE libraries which are exactly dll's be treated the same as
> library dll's? Of course, that may simply be incorrect background
> documentation above, but that is what that documentation says.)
>
> So in case that documenation is incorrect, try removing
>
> set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> and replacing it by
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> According to the documentation the net effect of setting that variable
> should be to collect all executables and
> the dll part of shared libraries into that dll directory, but it
> also makes sense to me it will collect the device driver dll's (built
> as modules) as well
> in that directory. But if the build location for the device drivers
> is not moved from drivers to dll by the above change, then try
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> instead which should work according to the documentation.
>
> And if setting one or both those variables works for you, please go
> ahead and commit the change so that Arjen can test it for his Windows
> platforms as well (which should also work according to the
> documentation of those variables).
>
> If no combination of setting either/both
> CMAKE_RUNTIME_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY
> locates the library and device driver dll's in the dll subdirectory,
> then we can only conclude that either the CMake version you are using
> or the generator you are using has a bug with regard to honoring the
> settings of CMAKE_RUNTIME_OUTPUT_DIRECTORY and
> CMAKE_LIBRARY_OUTPUT_DIRECTORY. Some additional tests by you with
> cmake-2.8.12.2 and the nmake generator would be required to sort out
> which, but hopefully, it will not come to that, and setting
> one or both the above variables will work for you.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
