"Alan W. Irwin" <[EMAIL PROTECTED]> writes:

> 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.
>

When I build with svn revision 7974 and have BUILD_SHARED_LIBS=ON and
ENABLE_DYNDRIVERS=OFF I get the following error during make

[  0%] Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.o
/usr/bin/gcc.exe  -Dcsirocsa_EXPORTS   /Zl   -DHAVE_CONFIG_H -DMAKINGCSADLL -o 
lib/csa/CMakeFiles/csirocsa.dir/csa.o   -c 
/cygdrive/m/software/source/scientific/plplot-svn/lib/csa/csa.c
gcc: /Zl: No such file or directory
make[2]: *** [lib/csa/CMakeFiles/csirocsa.dir/csa.o] Error 1
make[2]: Leaving directory `/opt/build/cygwin-no-ivf'
make[1]: *** [lib/csa/CMakeFiles/csirocsa.dir/all] Error 2
make[1]: Leaving directory `/opt/build/cygwin-no-ivf'
make: *** [all] Error 2

The "/Zl" option is not appropriate with gcc.  With the Microsoft C
compiler, "/Zl" means "omit default library information from the .obj",
which, we should use when building with the Microsoft C compiler.

> 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.
>

The problem with the Intel compiler is that the Windows version expects
that the forward slash denotes switches.  The Makefiles generated by
cmake in cygwin use the forward slash as path delimiters.  I use the
Windows Intel compiler in cygwin, but I have to make sure that I call it
the correct way.

Setting FC=ifort does not help the build.

> 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.
>

I'm not sure what a "full report" is, but the only way I can see the
Windows version of the Intel compiler working in cygwin is through the
judicious use of the cygpath command.  In my Makefile I have

# Set variables based on the target architecture
ifeq ($(ARCH),i686-pc-win32-ivf)
  #
  # Build environment for Intel Visual Fortran in win32
  #

  # Path translation command for cygwin
  fullpath=$(shell cygpath -a -m $1)
  unixpath=$(shell cygpath -a -u $1)

  ...snip...

    # Implicit rules
  ifeq ($(DEBUG), 0)
    # For non-debug builds I want to generate the optimization report
    # /Qopt-report = Generate optimization report
    # /Qopt-report-file = Destination of the report
%.o : %.f90
        $(FC) /compile_only $(FCFLAGS) \
          /Qopt-report /Qopt-report-file $*.rep \
          "$(call fullpath,$<)" /object:$@
  else
%.o : %.f90
        $(FC) /compile_only $(FCFLAGS) "$(call fullpath,$<)" /object:$@
  endif

%.o : %.c
        $(CC) /c $(CCFLAGS) "$(call fullpath,$<)" /Fo$@


> 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
>

$ cmake -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF
-DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON
-DDEFAULT_NO_BINDINGS=ON
/cygdrive/m/software/source/scientific/plplot-svn

The output files are attached.  I didn't bother to do the second test
because the first one failed.

Attachment: cmake-1.out
Description: Binary data

Attachment: make-1.out
Description: Binary data

Cheers

-jd
-------------------------------------------------------------------------
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