On 2013-07-10 13:15+0200 Arjen Markus wrote:
> Hi Alan,
>
> I have tried to build PLplot using this latest revision
> under Cygwin, but I run into the problem that apparently
> USE_RPATH is set now, so that the DLLs are not properly
> installed as under Windows in the directory "dll".
>
> I can not find where this variable is set. Do you know
> where it is coming from?
cmake/modules/rpath.cmake.
But I don't think that matters because I am virtually positive USE_RPATH
is not the issue. After my most recent change to reduce ambiguity
(but effectively this was not a logic change) the relevant code
concerning dll looks like this:
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)
That code started out as ... AND WIN32 AND NOT CYGWIN
You recently changed it to ... AND WIN32 (which is logically equivalent
for modern CMake/Cygwin where WIN32 true implies CYGWIN is false),
and I have now changed that back to
... AND WIN32_AND_NOT_CYGWIN (again logically equivalent to all the
rest) to reduce ambiguity about what is meant.
I then looked at other places in our code where /dll is mentioned.
software@raven> find -name CMakeLists.txt -o -name "*.cmake" \
|grep -v build_projects |xargs egrep '/dll([^a-zA-Z]|$)'
./bindings/ada/CMakeLists.txt: WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/dll
./drivers/CMakeLists.txt: PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR}/dll
./examples/python/CMakeLists.txt: set(python_location4
${CMAKE_BINARY_DIR}/dll)
./examples/lua/CMakeLists.txt: set(lua_lib_location ${CMAKE_BINARY_DIR}/dll)
./CMakeLists.txt: set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
Some were inside WIN32_AND_NOT_CYGWIN logic blocks and some were
inside WIN32_OR_CYGWIN logic blocks. As of revision 12414 I got rid of that
inconsistency by changing all references to dll to be inside
WIN32_AND_NOT_CYGWIN
logic blocks.
I am pretty sure that will work since historically CYGWIN never needed
the dll workaround that is required for all other Windows platforms.
But to check that please systematically run the following test steps
and whether you get success or not please send me the results I
request below.
1. Run cmake with -DBUILD_TEST=ON and do not say anything about
USE_RPATH since the default should be fine. No dll subdirectory should
be created. Please collect the cmake
output in cmake.out and also the CMake cache file as per my usual
request.
2. Run
make VERBOSE=1 test_noninteractive >& test_noninteractive.out
3. If (2) works, run
make VERBOSE=1 install >& install.out
However far you get with those steps, please send me a tarball with
all the *.out files and the CMake cache file.
Also, on Cygwin (if you install the relevant package) you should
have access to the "ldd" command. Please run that on some of
the libraries created as part of step 2 and send me those results as
well.
As a comparison here is one typical result on Linux:
software@raven> cd build_dir
software@raven> ldd -r src/libplplotd.so
linux-vdso.so.1 => (0x00007fffd8917000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7
(0x00007f80032d3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8003050000)
libcsirocsa.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0
(0x00007f8002e46000)
libcsironn.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0
(0x00007f8002c3f000)
libqsastime.so.0 =>
/home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0
(0x00007f8002a39000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x00007f800279a000)
libshp.so.1 => /home/software/shapelib/install/lib/libshp.so.1
(0x00007f8002589000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f80021fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8001ffa000)
libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5
(0x00007f8001d96000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8001b7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f800377a000)
Note, these results show there are no missing libraries, and all the
ones that are built in the build tree are found there rather than some
other inappropriate place. Furthermore, the -r option checks further
to make sure all symbols get defined by the libraries that are found.
Note, that rpath (which is used by fundamental CMake default for the
build tree for platforms like Linux and Cygwin that support rpath)
allows those build-tree libraries to be found. So if rpath is working
on Cygwin (like it has in the past for your builds) you should get
similar results to these, and all other results above should just
work.
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
__________________________
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
