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

Reply via email to