On 4/16/2011 9:35 PM, Alan W. Irwin wrote:
>
> This issue is taken care of properly on MinGW/MSYS by placing all the
> dll's in the dll subdirectory of the top-level build tree. I note the
> following logic in our top-level CMakeLists.txt file to implement this.
>
> # in windows all created dlls are gathered in the dll directory
> # if you add this directory to your PATH all shared libraries are
> available
> if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
> set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
> endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
>
> What happens if you drop the "AND NOT CYGWIN" from the if and endif
> statements? (CMake sets both WIN32 and CYGWIN to be true on the
> Cygwin platform.) I think you will find all relevant dll's collected
> in the dll subdirectory. After that, you get access to everything in
> the build tree by simply putting that directory on your PATH.I'm making that change and re-running the build. >> (3) After the install, the following two (at least) >> directories below need to be added the PATH for >> the plplot examples to run: >> >> <install-dir>/bin >> <install-dir>/lib/plplot5.9.7/driversd > > The first one is generally a requirement on Linux as well so adding an > additional one for the drivers on Windows should not be too > inconvenient. Sorry I don't yet grok cmake so I cannot fix these simple things (yet). > Yes, I have heard on the CMake list that most cross-platform > Linux/Windows projects build most reliably on Cygwin if you simply > replace all "WIN32" logic with "WIN32 AND NOT CYGWIN" (with the > obvious exception of cmake build-system logic like the above where you > want the dll's that are built to be treated in a windows-like way for > collecting them so they are easier to put on the PATH). The DLL vs shared library issues is one of the key places where cygwin can't quite hide all the windows issues. >> Now that I've got the plplot building [...] > > I suggest you test it as well. That is most easily done by using the > -DBUILD_TEST=ON cmake option, and running the test_noninteractive and > test_interactive targets in the build tree, e.g., > > make VERBOSE=1 test_noninteractive >& make_testnon.out > make VERBOSE=1 test_interactive >& make_test.out Thanks for the suggestions. I've added that to my build script and will let you know how things go. The first thing I had to do was disable python and lua as well since there are known DLL and compiler issues with interpreted languages on cygwin that use dynamic loading. Those issues can be worked out once the base plplot is working. > That captured output will have a lot of useful information for us if > anything goes wrong. Note, also that test_interactive target does > what it says so you will see lots of PLplot GUI's coming and going on > your screen. (The test is set up with the PLplot nopause option to > minimize the user intervention that is required to move through the > various interactive examples.) > > >> , I'm going to >> see if I can get it to talk to perl/PDL. I think >> that would be easier if I did not use dynamic drivers >> to reduce possible issues that could arise. >> >> Is there some way to build a static plplot with all the >> drivers linked in statically as well? That should >> simplify the next steps. > > The dll approach can be made reasonably convenient on Cygwin as well > (see the above suggestion for changing the CMake logic so the dll's > are collected in one subdirectory of the build tree), and that is > certainly the best-tested version of our software and has the big > advantage of keeping drivers completely divorced from our principal > library. However, if you want to try the static library (+ nondynamic > driver) approach where the driver code is lumped into our core (now > static) library rather than living separately, then I suggest you try > the -DBUILD_SHARED_LIBS=OFF cmake option. I'll keep you posted on this. My experience is that due to the many little differences between the .dll and "real" .so libraries, taking those link and runtime path issues out of the picture can make it much easier to sort out and fix plplot-specific issues. Thanks again for the help, Chris ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
