[Octave-bug-tracker] [bug #33018] ./configure considered broken

[John W. Eaton]

Follow-up Comment #11, bug #33018 (project octave):

In the err.log file you attached, you have


./configure CFLAGS="-g -I/app/include " LDFLAGS="-L/app/lib
-L/opt/SUNWspro/prod/lib" LIBS="-lgmp -lsunperf" FFLAGS="-g " F77="f90 -f77 "
| & tee make.log

NB: For convenience /opt/SUNWspro -> /opt/solstudio12.2


So this allows the configure script to find a working Fortran compiler?

Then you have


I don't know if this is a bug in the Bourne shell or just a bashism.  It looks
like a bug to me.  Changing the Makefile.in "SHELL = /bin/bash" fixes this:

/bin/sh ../libtool --tag=F77   --mode=compile f90 -f77  -g  -g  -c -o
ranlib/advnst.lo ranlib/advnst.f
../libtool: syntax error at line 659: `func_arith_result=$' unexpected
make[2]: *** [ranlib/advnst.lo] Error 2
make[2]: Leaving directory `/app/pkgs/octave/octave/octave-3.4.0/libcruft'


The libtool script is generated by configure.  The one that is generated on my
system begins with


#! /bin/bash


so it is intended to be a bash script.  But yours may be different.  In any
case, this would be a bug in libtool, not Octave.  What exactly is the code at
line 659 in your libtool script?  Please also show some context there.

The next problem you show is


libtool: compile:  f90 -f77 -g -c arpack/util/second.f  -KPIC -o
arpack/util/.libs/libcruft_la-second.o
arpack/util/second.f:
        arscnd:

      INTRINSIC          ETIME
                         ^     
"arpack/util/second.f", Line = 24, Column = 26: ERROR: "ETIME" is not an
intrinsic routine.


Try replacing INTRINSIC with EXTERNAL in libcruft/arpack/utils/second.f.

Then you have


make[2]: *** [arpack/util/libcruft_la-second.lo] Error 1
make[2]: Entering directory `/app/pkgs/octave/octave/octave-3.4.0/libcruft'
This is the part I've been unable to fix.  liboctinterp.so keeps getting
rebuilt for some reason.  It appears to be trying to incrementally add things
to the library, but it's not at all clear.


I don't understand.  Are you running make again, or is a single invocation of
Make somehow looping after the error.  If I modify the second.f file so that
there is a syntax error in it and run Make from the top-level of my build
tree, it just stops after failing to compile second.f.

Finally, you have


libtool: link: g++ -shared -nostdlib  /usr/lib/crti.o /usr/lib/values-Xa.o
/app/pkgs/gnu/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/crtbegin.o 
amos/.libs/libcruft_la-cacai.o [snip] slatec-fn/.libs/libcruft_la-xerfc.o
slatec-fn/.libs/libcruft_la-xsgmainc.o slatec-fn/.libs/libcruft_la-xgamma.o
slatec-fn/.libs/libcruft_la-xbetai.o  -Wl,-z -Wl,allextract
../libgnu/.libs/libgnu.a ./.libs/libranlib.a -Wl,-z -Wl,defaultextract  -Wl,-R
-Wl,/app/pkgs/gnu/gmp/4.3.2/lib -Wl,-R -Wl,/app/pkgs/gnu/gcc/4.5.0/lib -Wl,-R
-Wl,/app/pkgs/gnu/gmp/4.3.2/lib -Wl,-R -Wl,/app/pkgs/gnu/gcc/4.5.0/lib -Wl,-R
-Wl,/opt/solstudio12.2/lib -L/app/lib -L/opt/SUNWspro/prod/lib -lsocket -lrt
-lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk
/app/pkgs/gnu/gmp/4.3.2/lib/libgmp.so -lsunperf
-L/app/pkgs/gnu/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0
-L/app/pkgs/gnu/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/../../..
/app/pkgs/gnu/gcc/4.5.0/lib/libstdc++.so -lm -lgcc_s
/app/pkgs/gnu/gcc/4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/crtend.o
/usr/lib/crtn.o  -mieee-fp -pthreads   -pthreads -Wl,-h -Wl,libcruft-3.4.0.so
-o .libs/libcruft-3.4.0.so
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x9        
/opt/SUNWspro/prod/lib/libfui.a(etime_.o)

[snip] 

<unknown>                           0x18       
/opt/SUNWspro/prod/lib/libfui.a(etime_.o)
__sinh                              0x46       
/opt/SUNWspro/prod/lib/libsunmath.a(sinhf.o)
__cosh                              0x36       
/opt/SUNWspro/prod/lib/libsunmath.a(coshf.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status


What part did you [snip]?  I expect that the etime problem might be related to
the problem compiling second.f.  I have no idea about why __sinh and __cosh
are not found.  Octave does not reference those symbols directly, so there
must be something missing or incorrect about the list of system libraries that
you are linking with.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33018>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/