octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building Octave with Intel C++/F9x


From: Giuseppe Ragusa
Subject: Building Octave with Intel C++/F9x
Date: Fri, 7 Jun 2002 02:08:51 +0200

I'm the guy that Mumit Khan kindly helped build Octave with Intel
compilers.
Since now I have Octave 2.1.36 successfully built with Intel
C++/FORTRAN but the steps I followed differ slightly from those
described in Mumit's recent messages to this list, I'll summarize up
what I did to have it up and running (albeit not heavily tested yet).
Keep in mind that I'm using a plain standard Red Hat 7.3 ix86 box with
Intel C/C++/F90 compilers (release 6.0) and I was trying to build an
rpm package of octave 2.1.36 (I actually started working from an
octave-2.1.36-1.src.rpm found on Red Hat rawhide, alas alpha software,
archives). I'll skip rpm/spec building details. Note that Red Hat 7.3
comes with autoconf 2.13 (no cvs octave with these tools...).
I'll refer to Mumit Khan's previous messages on the same subject.

1) I had previously rebuilt (using Intel Fortran) the following
packages:
lapack/blas
fftw
HDF (4.x)
hdf5

I can assure you that neither these steps were painless...
Maybe one of the below noted workarounds is due to some errors on
recompiling these packages (see note on -lPEPCF90 below).

Now on to octave rebuilding:

2) Mumit accurately reported autoconf problems in autodetecting
compiler flags; I overcame these limitations/bugs manually including
the appropriate flags into environment variables (after watching what
configure was trying to achieve); the incorrect flags kept being used,
but fortunately Intel compilers simply warned about them.
Flags are listed below (at point 4).
Specifically note that:
ifc : Intel fortran compiler
icc : Intel c/c++ compiler
-O3 -tpp5 -ip : "conservative" (really?) optimization flags for icc/ifc
-C90 : ifc switch needed for fortran/c/c++ mixed I/O (really needed?)
-mp : icc/ifc equivalent of -mieee-fp (really needed?)
-lPEPCF90 : apparently not autodected (linking failed on etime_ causing
liblapack not being found by configure and other errors)

3) configure kept failing (as Mumit noted) because of incorrectly
parsed output (in libraries list) containing double quotes; I took the
quick and dirty approach of patching configure script with:

--- configure   Wed May  1 09:10:38 2002
+++ configure.new       Mon Jun  3 23:19:00 2002
@@ -6432,7 +6432,8 @@
   # If we are using Cray Fortran then delete quotes.
   # Use "\"" instead of '"' for font-lock-mode.
   # FIXME: a more general fix for quoted arguments with spaces?
-if echo $ac_f77_v_output | grep cft90 >/dev/null 2>&1; then
+# WORKAROUND: Intel Fortran Compiler needs this fix too
+if echo $ac_f77_v_output | egrep '(cft90)|(f90com)' >/dev/null 2>&1;
then
     ac_f77_v_output=`echo $ac_f77_v_output | sed "s/\"//g"`
   fi

4) Finally, I successfully ran configure with:

LC_ALL=POSIX
F77="ifc"
FFLAGS="-O3 -tpp5 -ip -C90 -mp -lPEPCF90"
CC="icc"
CFLAGS="-O3 -tpp5 -ip -mp"
CXX="icc"
CXXFLAGS="-O3 -tpp5 -ip -mp"
export LC_ALL F77 FFLAGS CC CFLAGS CXX CXXFLAGS
./configure  --enable-dl --enable-shared=yes \
--enable-rpath --enable-lite-kernel \
--enable-picky-flags --enable-static=no \
--prefix=/usr

As noted in an Intel provided doc (LinuxCompilersCompatibility60.pdf)
you currently must use Intel icc as your C++ compiler if you're gonna
mix C++ and FORTRAN code.

5) then building failed on src/c-file-ptr-stream.h; there I used part
of a patch Mumit had personally sent me together with a patch (again
from Mumit) I found on this mailing list archives, regarding GCC 3.1
related corrections:

--- src/c-file-ptr-stream.h     Fri Nov  2 06:12:00 2001
+++ src/c-file-ptr-stream.h.new Wed Jun  5 04:46:57 2002
@@ -31,13 +31,37 @@
   #include <fstream>
   #include <cstdio>
   +//
+// The c_file_ptr_buf requires a std::filebuf that accepts an open
+// file descriptor. This feature, while not part of the ISO C++
+// standard, is supported by a variety of C++ compiler runtimes,
+// albeit in slightly different ways.
+//
+// The C++ runtime libraries shipped with GCC versions < 3.0, Sun Pro,
+// Sun Workshop/Forte 5/6, Compaq C++ all support a non-standard filebuf
+// constructor that takes an open file descriptor. The almost ISO compliant
+// GNU C++ runtime shipped with GCC 3.0.x supports a different non-standard
+// filebuf constructor that takes a FILE* instead; starting from GCC 3.1,
+// the GNU C++ runtime removes all non-standard std::filebuf constructors
+// and provides an extension template class __gnu_cxx::stdio_filebuf
+// that supports the the 3.0.x behavior.
+//
+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+# include <ext/stdio_filebuf.h>
+# define OCTAVE_STD_FILEBUF __gnu_cxx::stdio_filebuf<char>
+#else
+# define OCTAVE_STD_FILEBUF std::filebuf
+#endif
+
   class
-c_file_ptr_buf : public std::filebuf
+c_file_ptr_buf : public OCTAVE_STD_FILEBUF
   {
   public:
    #if !defined (CXX_ISO_COMPLIANT_LIBRARY)
     typedef int int_type;
+#else
+  typedef std::filebuf::int_type int_type;
   #endif
      typedef int (*close_fcn) (FILE *);
@@ -47,9 +71,11 @@
     c_file_ptr_buf (FILE *f_arg, close_fcn cf_arg = ::fclose)
       :  #if defined __GNUC__ && __GNUC__ >= 3
-    std::filebuf (f_arg, std::ios::in | std::ios::out),
+    OCTAVE_STD_FILEBUF (f_arg, std::ios::in | std::ios::out),
+#elif defined __INTEL_COMPILER
+    OCTAVE_STD_FILEBUF (f_arg),
   #else
-    std::filebuf (f_arg ? fileno (f_arg) : -1),
+    OCTAVE_STD_FILEBUF (f_arg ? fileno (f_arg) : -1),
   #endif
       f (f_arg), cf (cf_arg),
       fd (f_arg ? fileno (f_arg) : -1)
@@ -94,6 +120,8 @@
     int fd;
   };
   +#undef OCTAVE_STD_FILEBUF
+
   class
   i_c_file_ptr_stream : public std::istream
   {


6) Finally, I successfully ran make as:

make CFLAGS="-O3 -tpp5 -ip -mp" CXXFLAGS="-O3 -tpp5 -ip -mp"


I'd like to note that I have still not run extensive tests on the
octave binaries I got from this process, but I verified they produce
results that partially match those obtained with Sun Forte and were
reported as "strange" (or so deduced I) in previous messages to this
mailing list:

octave:1> sin(0)
ans = 0
octave:2> sin(pi)
ans =  1.2246e-16
octave:3> sin(pi/2)
ans = 1
octave:4> sqrt(-1)
ans = 0 + 1i
octave:5> eps
eps =  2.2204e-16

Note that I didn't manually set the FLIBS variable as more recently
suggested by Mumit, nor I edited Makeconf to change CXXFLAGS or
XTRA_CXXFLAGS to remove -Wall -mieee-fp or change -fPIC to -kPIC
neither I had applied his other (rated "generic") patches.
Again, remember I'm not using current cvs sources (see note above old
RedHat-provided autoconf-tools) but I use standard 2.1.36.

Hope to have helped a bit clarifying this issue.

Finally: many many thanks again to Mumit and all of you whose comments
on this mailing list archives I perused for some time.

Best regards,
                Giuseppe Ragusa



reply via email to

[Prev in Thread] Current Thread [Next in Thread]