Hi Phil,
I will definitely try these changes with Cygwin and MinGW. Pairs of functions
for handling ASCII and UNICODE strings are ubiquitous under Windows and I do
not expect trouble like Cygwin or MinGW not supporting the two flavours. Still,
that needs to be checked.
Glad you have been able to sort out these path issues.
Regards,
Arjen
From: Phil Rosenberg [mailto:philip_rosenb...@yahoo.com]
Sent: Tuesday, September 23, 2014 12:13 PM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] tcl build problem
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.
Arjen - you have more Cygwin experience than me. I assume these changes will
work just fine in Cygwin, but if you know better let me know.
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.
Phil
________________________________
From: Alan W. Irwin<mailto:ir...@beluga.phys.uvic.ca>
Sent: 23/09/2014 02:58
To: Phil Rosenberg<mailto:philip_rosenb...@yahoo.com>
Cc: PLplot development list<mailto: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
__________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
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
