On 2007-10-24 21:39-0400 Jim Dishaw wrote: > Jim Dishaw <[EMAIL PROTECTED]> writes: > >> "Alan W. Irwin" <[EMAIL PROTECTED]> writes: >>> Jim, please correct me if you have a different experience, but my belief is >>> the environment variable approach is going to set the fortran compiler and >>> its options completely consistently so there should be no inconsistent extra >>> options like "/DIVF" unless the build was done starting from a dirty build >>> tree. >>> [...]Jim, what happens if you try that simple case on Cygwin for 5.8.0-RC1? >> > > I downloaded the 5.8.0-RC1 source tarball and followed the build > instructions on the Wiki for cygwin. > > First, I was not able to get things working without specifying > -DBUILD_SHARED_LIBS=OFF.
To Jim, Arjen, and Hiroyasu: Jim, I asked for a 5.8.0-RC1 test above, but since then I made a Cygwin fix in the svn version so I hope you (and also Arjen and Hirosyasu) will also do the two simple tests of the SVN version requested below. For 5.8.0-RC1, you probably had to specify -DBUILD_SHARED_LIBS=OFF because that version doesn't have my fix. Nevertheless, the -DBUILD_SHARED_LIBS=OFF test is interesting in its own right so I will discuss that first before referring to the simple -DBUILD_SHARED_LIBS=ON tests I need as well. > > If you start with a clean directory and specify FC=g77 then everything > builds correctly with Intel Fortran in the path and TARGET_FORTRAN is > blank (as it should be). It's good to hear you have had that success with FC=g77 in the static libraries (-DBUILD_SHARED_LIBS=OFF) case. Jim, what happens if you specify FC=ifort? Note, the FC environment variable method is documented on our wiki. We also give another non-FC alternative for specifying the fortran compiler, but that turns out not to be as reliable so we should remove that non-FC alternative from the wiki until the associated cmake bug that makes it unreliable gets fixed. I am pretty sure we have tested the ifort compiler before on Cygwin using the FC approach with positive results, but if the path problem you have found previously with a non-FC approach persists for the FC approach, then please give a complete report, and we might be able to fix it or get help on the Cmake mailing list for the problem. It is good that the -DBUILD_SHARED_LIBS=OFF works for you on Cygwin (at least for the g77 compiler), but that static library approach results in really bulky executables and forced dropping of a number of our bindings (such as Python and Java) which is why it is important to get the default shared library approach to work on Cygwin as well (with or without dynamic devices). Your present -DBUILD_SHARED_LIBS=OFF tests of 5.8.0-RC1 are not affected by the extra fixes I committed after that release since those fixes only affect the (important) case of shared libraries. However, if you are willing to do further simple tests of the shared libraries case you should only use the latest SVN trunk version of PLplot. Those two tests are as follows (each should be done with an initially empty build tree, and I would appreciate a complete report (at least cmake command line, cmake.out, and make.out) for each. (1) The first test should have the following options: -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF -DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON The first two options turn on shared libraries but turn off dynamically loaded device drivers. The third option adds essential information to make.out. The last three options turnd off all devices other than ps and turns off all bindings except the core native C binding. They simplify the test which makes it run much quicker and more importantly removes a lot of interdependencies which might obfuscate issues. (2) The second test should have the following options -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=ON -DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON This set of options is identical to the previous set except that dynamically loaded device drivers are turned ON. Jim, thanks in advance for a complete report of both simple cases on your Cygwin platform using the latest SVN version of PLplot. Arjen and Hiroyasu it would be good if you gave complete reports of exactly the same two requested simple tests on your own Cygwin platforms since the issues (if they exist with the latest svn version) may depend on exact details (e.g., what version of required Cygwin dynamical loading libraries are installed) of your various Cygwin platforms. Hiroyasu, you have already posted a most helpful complete report for version 5.7.4 of PLplot of the simple test (2) above (-DBUILD_SHARED_LIBS and -DENABLE_DYNDRIVERS were not specified for your test which means they both defaulted to ON as in the above test 2). It should be a relatively simple matter for you (and the others) to repeat that test (and also do test 1) for our latest svn version of PLplot. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
