Fri 10 Feb 2012 05:54:09 PM UTC, comment #11:
Closing bug as it was filed against a release candidate for 3.4. This bug can be re-opened, or re-filed, if the reporter can verify that the problem is still present. The latest release candidate for 3.6.1 is available at ftp://alpha.gnu.org/gnu/octave/.
|
Wed 02 Mar 2011 03:49:02 AM UTC, comment #10:
I make the change you requested. I commented out line 24 and made a copy of that line just underneath it and changed the INTRINSIC keyword to EXTERNAL. That solved that bug but the compile failed at another stage. It is with the C++ code that the failures occurred when I first tried to compile the software. I am going to post a log of the compile attempt.
(file #22823)
|
Wed 02 Mar 2011 03:47:49 AM UTC, comment #9:
I make the change you requested. I commented out line 24 and made a copy of that line just underneath it and changed the INTRINSIC keyword to EXTERNAL. That solved that bug but the compile failed at another stage. It is with the C++ code that the failures occurred when I first tried to compile the software. I am going to post a log of the compile attempt.
|
Wed 02 Mar 2011 03:45:46 AM UTC, comment #8:
I make the change you requested. I commented out line 24 and made a copy of that line just underneath it and changed the INTRINSIC keyword to EXTERNAL. That solved that bug but the compile failed at another stage. It is with the C++ code that the failures occurred when I first tried to compile the software. I am going to post a log of the compile attempt.
|
Tue 01 Mar 2011 03:55:45 AM UTC, comment #7:
It seems that there is some disagreement as to whether etime should be an intrinsic Fortran function. The GNU compiler gfortran and the AT&T-derived Fortran compiler on Mac OS X apparently both make it an intrinsic function where Solaris does not.
Could you try replacing "intrinsic" with "external" on the problem line (second.f:24) and re-compiling?
|
Thu 24 Feb 2011 12:32:12 AM UTC, comment #6:
Now I get a different error. I was able to configure the code but the compilation ended with the following error...
/bin/sh ../libtool --tag=F77 --mode=compile /opt/ssdev/solstudio12.2/bin/f90 -dalign -c -o arpack/util/libcruft_la-ivout.lo `test -f 'arpack/util/ivout.f' || echo './'`arpack/util/ivout.f
libtool: compile: /opt/ssdev/solstudio12.2/bin/f90 -dalign -c arpack/util/ivout.f -KPIC -o arpack/util/.libs/libcruft_la-ivout.o
/bin/sh ../libtool --tag=F77 --mode=compile /opt/ssdev/solstudio12.2/bin/f90 -dalign -c -o arpack/util/libcruft_la-second.lo `test -f 'arpack/util/second.f' || echo './'`arpack/util/second.f
libtool: compile: /opt/ssdev/solstudio12.2/bin/f90 -dalign -c arpack/util/second.f -KPIC -o arpack/util/.libs/libcruft_la-second.o
INTRINSIC ETIME
^
"arpack/util/second.f", Line = 24, Column = 26: ERROR: "ETIME" is not an intrinsic routine.
f90comp: 36 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
gmake[2]: *** [arpack/util/libcruft_la-second.lo] Error 1
gmake[2]: Leaving directory `/home/juan/octave-3.4.0/libcruft'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/juan/octave-3.4.0'
gmake: *** [all] Error 2
^C
I will upload some log files for the developers to review.
|
Wed 23 Feb 2011 06:35:57 PM UTC, comment #5:
Ok. I will attempt to compile the code again when I get home from work this evening. I plan to download the latest development release and recompile. I will post the results here.
|
Wed 23 Feb 2011 03:36:56 PM UTC, comment #4:
Quite a lot has changed since 3.3.54; there has been over 1,100 changesets pushed between that version and the new 3.4.0. None of Octave's principal developers have Solaris systems to verify compilation.
|
Wed 23 Feb 2011 02:10:21 PM UTC, comment #3:
I haven't had time to compile it recently. However, since nothing has changed since I submitted the bug the chances are very good the bug still continues. Have you guys tried to compile the code on Solaris 11 express for yourself? The problem will occur both on Solaris 10 and Solaris 11 express. The compiler suite and the operating system can be downloaded for free from Oracle if used for development purposes.
|
Mon 21 Feb 2011 02:14:13 AM UTC, comment #2:
Are you still unable to compile from source using the new 3.4.0 release?
|
Sun 19 Dec 2010 12:52:44 AM UTC, comment #1:
Although this is redundant because it is the same text as you can find in the run_config.sh script I am going to put it here anyway. It might save a minute or two from having to locate the info...
I am trying to compile Octave sources on Oracle (Formerly Sun) Solaris 11 Express using the Solaris Studio 12.2 compiler suite. The build options I provided to configure are as follows...
./configure --prefix=/opt/local --with-blas=/opt/ssde/solstudio12.2/lib/libsunperf.so --with-lapack=/opt/ssdev/solstudio12.2/lib/libsunperf.so CC=/opt/ssdev/solstudio12.2/bin/cc CXX=/opt/ssdev/solstudio12.2/bin/CC F77=/opt/ssdev/solstudio12.2/bin/f90 FFLAGS=-dalign
|
Sun 19 Dec 2010 12:46:54 AM UTC, original submission:
Build of latest TEST version of Gnu Octave fails on Oracle Solaris 11 Express using the Solaris Studio 12.2 compiler suite.
|