bugGNU Octave - Bugs: bug #33018, ./configure considered broken

 
 

bug #33018: ./configure considered broken

Submitter:  None
Submitted:  Thu 07 Apr 2011 05:50:52 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  Reginald Beardsley Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.4.0
Operating System:  * Other Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 16 Feb 2012 12:12:31 AM UTC, comment #30: 

Closing report as it deals with a deprecated version of Octave.  Reporter can re-open, if necessary, with new data from 3.6.1.

Rik <rik5>
Group administrator
Mon 18 Apr 2011 01:52:32 PM UTC, comment #29: 

For maximum trolling effect, I recommend that you post your criticisms of autotools to the autoconf, automake, and libtool lists.

John W. Eaton <jwe>
Group administrator
Sat 16 Apr 2011 04:11:32 PM UTC, comment #28: 

FYI  I've abandoned my efforts to build Octave on Solaris.  It makes a little more progress if I specify static libraries, but there are many failures in the makefiles and so many compiler warnings that I would not trust the program if it did eventually link.  I'm forced to conclude that the problems are so extensive that it's pointless for me to spend any more time on this.  If  anyone wants to investigate or fix it, they'll have to download Solaris 10 x86 U8 and setup a system. 

I've attached a couple of PDF files which try to elucidate the problem as I see it.  I'll eventually merge the two, but for now they are separate essays.


(file #23260, file #23261)

Reginald Beardsley <rhb>
Sun 10 Apr 2011 11:31:38 PM UTC, comment #27: 

John,

It's not reproducible and I'd deleted the work area I used.  I've been building other stuff, so configure sees a different environment.  Strangely tar-1.26 still has the problem.

The assembler emits a message about the temporary .s file:

 ".align test amount has a negative value"

It's not a message I've ever seen before and I'm not interested enough to chase it down.  I've gotten very used to certain releases of Gnu software don't work.  I have no reason to prefer an uncompilable tar-1.26 over a compilable tar-1.25.  If that changes I'll look into it.

As far as I'm concerned, at this time the mktime.c error is just background noise.  I don't care about stuff like that after spending 50+ hours battling autoconf & frenemies.   Once I can compile the whole thing, I'm quite happy to do it all over again and document what the fixes were.  So far I'm not even close because Octave wants to create a shared library the same way it creates an executable.  That's wrong by inspection, but despite an absurd amount of work, I can't find why because the instructions get rewritten on the fly more times than I can count.

Just for reference I took a job once taking over support for 1.25 million lines of X/Motif code that some other people had written.  Two of them still worked for the company.  It took me 6 weeks to track down all the undefined references and write working Makefiles for all of it.  I had to run find & nm across pretty much the entire filesystem.  I rather suspect that if you build out a new system and try to build Octave, you'll find it doesn't work the way it does on your regular system.  Hopefully I'm wrong, but I can't see any way that the arguments passed to libtool to create a shared library can be correct on any system.  Every time that it tried to create a shared library it tried to include a very large pile of redundant objects.  We know it's not libtool, because the problem is not w/ libtool, but the arguments passed to it.

I want to take a break from this for a week or so.  I'll let you know when I look into it again.

Regards,
Reg

Reginald Beardsley <rhb>
Sun 10 Apr 2011 08:27:15 PM UTC, comment #26: 

Previously, you wrote:


I had a failure compiling libgnu/mktime.c that I hadn't noticed before. I encountered the same failure building Gnu tar 1.26, but had no problems w/ 1.25, so I copied that version to Octave so that make could continue on to the library creation.


This is another instance of you saying that you had some failure and you fixed it somehow, but for which you provided no details explaining precisely what the failure was or how you fixed it.

I'm sorry I wasn't more explicit about exactly which omission I was referring to.

John W. Eaton <jwe>
Group administrator
Sun 10 Apr 2011 06:36:53 PM UTC, comment #25: 

"I keep saying this, but you don't seem to be getting it: "

I have told you what happened and what I did multiple times.  And you keep complaining.

But once again:

changed /bin/sh to /bin/bash in the Makefile.in files to fix the parse error in libtool.  I'm not about to take on regenerating things that come in the tarball if I can avoid it.

changed INTRINSIC to EXTERNAL in seconds.f to keep the Sutdio compiler happy

Swapped the mktime.c from tar-1.25 for the one in Octave (only when using the R libtool.  Not before)

Every time I build anything I keep a complete log of all the console output for the entire process.  Bear in mind that I build from source because I'm picky.  I want to be able to recompile w/ debugging on and fix a problem if I encounter one. I also want to see how many compiler & linker warnings get triggered as it's a useful barometer of whether a package will prove worthwhile using.

I unpacked a fresh copy of Octave from the tarball for the trial of the R libtool, so I knew I needed to fix the first two.  Because I'd just built Gnu tar I knew to do the last when I saw it.

I've told you all this before.

When I started on this some 50+ hours ago, I thought I'd be able to give you a detailed explanation of what was wrong and how to fix it,  I've been fixing software written by other people for many years.  I'm also able to write software that compiles w/o problems on anything around w/o the ministrations of imake or autoconf & frenemies.  I don't have any problem w/ expecting the person building the software to know how to do things on their own system.

Had I realized what I was getting into, I'd have just either used 2.1.73 on Solaris or booted Linux and run a more recent binary distribution as most people do.   However, I'm stubborn and rather unwilling to allow a computer to beat me.  Unfortunately, I've concluded that the computed goto from hell has.  I'm sick of trying to find where things get defined.  I would have compiled Octave successfully in no more than a couple of hours but for the constant massaging and mangling of the build instructions by an apparently denumerably infinite number of programs.  Discoverability is an important attribute.  Autoconf & company sadly have a very low score on that mark.

Reginald Beardsley <rhb>
Sun 10 Apr 2011 05:26:39 PM UTC, comment #24: 

The FLIBS options that I tried putting in the text box on savannah inside a verbatim block were:


FLIBS =  -L/opt/SUNWspro/prod/lib -L/app/lib
 -L/usr/lib -lm -R/opt/solstudio12.2/lib -lfai
 -lfui -lfsu -lsunquad -lsunmath -lmtsk


They actually are all there on the web site too, but there are apparently some problems with the tracker making it clear that a long line can be scrolled horizontally.

John W. Eaton <jwe>
Group administrator
Sun 10 Apr 2011 05:20:44 PM UTC, comment #23: 

I keep saying this, but you don't seem to be getting it:

If you are interested in helping improve Octave, then you are going to have to tell us PRECISELY what the failures are, not just that you had a failure and that you fixed it somehow.

John W. Eaton <jwe>
Group administrator
Sun 10 Apr 2011 04:58:11 PM UTC, comment #22: 

FWIW

I tried copying the libtool generated by R to the Octave directory.  It runs into the same malformed attempt to create a shared library as the one that Octave creates.

I had a failure compiling libgnu/mktime.c that I hadn't noticed before.  I encountered the same failure building Gnu tar 1.26, but had no problems w/ 1.25, so I copied that version to Octave so that make could continue on to the library creation.

Reginald Beardsley <rhb>
Sun 10 Apr 2011 04:41:34 PM UTC, comment #21: 

Life would be simpler if this were made more clear:

(Note: upload size limit is set to 512 kB, after insertion of the required escape characters.)

I interpreted that to mean that the limit applied to individual files which it turns out is not true.

Reginald Beardsley <rhb>
Sun 10 Apr 2011 04:24:35 PM UTC, comment #20: 

Here's the other one.

(file #23190)

Reginald Beardsley <rhb>
Sun 10 Apr 2011 04:23:29 PM UTC, comment #19: 

I included both the libtool files as requested.  I'm attaching them again.

!! The FLIBS presented on savannah are not the same as in your email !!

FLIBS =  -R/opt/solstudio12.2/lib -lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk -lm



(file #23189)

Reginald Beardsley <rhb>
Sun 10 Apr 2011 04:06:28 PM UTC, comment #18: 

I also asked for the libtool script for your Octave build and the libtool script for you R build so I can compare them.

Those files are generated by the build process and are system dependent, so looking at the scripts that are generated for my system won't help me.  But seeing the ones generated for your system may give me a clue about what is causing the trouble.

Looking at the generated Makefile, I see


FLIBS =  -L/opt/SUNWspro/prod/lib -L/app/lib -L/usr/lib -lm -R/opt/solstudio12.2/lib -lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk


What does the R configure script determine for FLIBS on your system?

Also, although the configure script for R does appear to generate a libtool script, I don't see where it is ever actually used in the build process for R itself.  See the comments and following code for "DLL stuff" in the R configure.ac file.  That is the kind of cruft I hope to avoid in Octave by using libtool.  If libtool has problems on some systems, then we should fix libtool, not introduce system-specific magic into Octave's configure scripts.  My reasoning for this is that it makes more sense for us to improve libtool to help all projects which use it rather than just "fixing" Octave, and it is not likely that we will do a much better job of getting all these details right for many systems than do the libtool developers.

John W. Eaton <jwe>
Group administrator
Sun 10 Apr 2011 12:49:54 PM UTC, comment #17: 

As requested.

(file #23187)

Reginald Beardsley <rhb>
Sun 10 Apr 2011 02:19:30 AM UTC, comment #16: 

Please attach your your generated libcruft/Makefile and the generated libtool script for Octave.

It would also be helpful if you attached the libtool script that was generated when you built R, as I'd like to see what the differences are.

John W. Eaton <jwe>
Group administrator
Sat 09 Apr 2011 09:56:40 PM UTC, comment #15: 

FYI

I just built R from source.  I don't like R, but it's the only thing I could think of that's a fair comparison to Octave for size and complexity.  Really large is much harder than merely big.

The only glitch was a dependency on Gnu libiconv.  Otherwise the environment and configure arguments were the same as for Octave.

I think that exonerates autoconf, automake and libtool.

Reginald Beardsley <rhb>
Sat 09 Apr 2011 09:07:57 PM UTC, comment #14: 

I can't find any instructions for highlighting :-(

From the err.log file I sent earlier:

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

ld -G -h libcruft-3.4.0.so -o .libs/libcruft-3.4.0.so ${OBJS}

works to create a shared library.  This may be an autoconf bug.  I haven't tried to compile on Fedora to see what gets done there."


crti.o crtend.o crtn.o are being linked when creating libcruft.so.  Those are for linking an executable.

It makes no logical sense that I can see to reference all the other libraries.  You certainly can't check for undefined references while you're still building libraries.  The spew of relocation failures arises when libtool and/or g++ pick up static libraries rather than the dynamic version.  I'd built quite a few packages with little trouble before I started on Octave.  The only glitch was a package required by gcc which autoconf defaulted to 64 bit instead of 32 bit.  Admittedly only gcc comes anywhere near as big as Octave.

All the libraries attempt to include crti.o, crtend.o & crtn.o which will cause lots of multiple definitions when the executable is linked.

Also from err.log:

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

Reginald Beardsley <rhb>
Sat 09 Apr 2011 07:52:40 PM UTC, comment #13: 

I think you are a bit confused about how common.mk is used  It is included in Makefile.am, so automake copies that to Makefile.in.  But in any case, it should probably not have SHELL = /bin/sh hardwired there.

Precisely what do you mean by


The library problem showed up making libcruft.so. I created it by hand and restarted make.


HOW did you "create it by hand"?  Unless we know what commands actually work, how can we fix the problem?  You have to provide some details if you want to see these problems fixed in a future version of Octave.


It ran on for a while only to fall over creating liboctave.so. Again fixed by hand.


Precisely what were the problems, and what did you do so that they were "fixed by hand"?  Likewise for the problems you encountered with liboctinterp.so.

 Then it started falling over creating liboctinterp.so. After 5-6 failures I finally gave up.

Precisely what do you mean by


The C runtime files don't belong in a shared library [...] Nor do all the other libraries.


Precisely which files are you referring to?  Which libraries?

If you mean the files like

+verbatim+/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
-verbatim-

then I think those are added to the link command by libtool.  If the list is not correct, then the bug is in libtool, not Octave.
I'm willing to help you report this problem and get it fixed in libtool if in fact it is a bug, but you will have to help by providing some information.  It would probably help to see your generated libcruft/Makefile and the generated libtool script.

John W. Eaton <jwe>
Group administrator
Sat 09 Apr 2011 06:06:40 PM UTC, comment #12: 

FYI I ran ./configure once and make 3 times.

configure finds the FORTRAN compiler just fine.  The key is:

 -L/opt/SUNWspro/prod/lib

There is certainly an error in autoconf's attempt to discover the FORTRAN library list.


The /bin/sh vs /bin/bash problem is in Makefile.in, not configure.  There's also a "SHELL = /bin/sh" in common.mk, but changing the Makefile.in references appears to solve the problem.

  The line is:

    func_arith_result=$(( $* ))


I changed INTRINSIC to EXTERNAL and restarted make to get to the shared library error.

The library problem showed up making libcruft.so.  I created it by hand and restarted make.  It ran on for a while only to fall over creating liboctave.so.  Again fixed by hand.  Then it started falling over creating liboctinterp.so.  After 5-6 failures I finally gave up.

The failure has nothing to do w/ etime.  That reference is from Sun's FORTRAN runtime library, not from arpack.  The problem appears to be the result of trying to link the static libraries w/ the objects in a shared library.

What I snipped was a very long list of object files.  I was very careful not to snip anything else.  The C runtime files don't belong in a shared library which is what I was trying to show.  Nor do all the other libraries.  Gnu ld may be happy w/ this, but the Solaris ld is not.  To the best of my knowledge gcc on Solaris has always used the Sun ld by default.  However, I find why autoconf chooses a particular version of an executable rather mysterious.


Reginald Beardsley <rhb>
Sat 09 Apr 2011 03:55:48 PM UTC, comment #11: 

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.

John W. Eaton <jwe>
Group administrator
Sat 09 Apr 2011 02:55:58 PM UTC, comment #10: 

Apparently something triggered an error cascade in configure.  Aside from the suitesparse problem, I had awk vs nawk failures and lots of problems finding libraries which I fixed w/ CFLAGS, LDFLAGS  & LIBS.  The problems are not reproducible.

Attached is a log of errors from a fresh run of ./configure & make w/ the configure arguments. 

The serious problems seem to be related to gcc using the Solaris ld, rather than the Gnu version.  But I could be mistaken.  I can't see any reason that one would include crti.o and friends to build a shared library.

I gave up after creating liboctinterp-3.4.0.so multiple times.

BTW My glpk is built using gmp, so configure fails w/o a "-l gmp" in LIBS

(file #23177)

Reginald Beardsley <rhb>
Sat 09 Apr 2011 02:15:36 AM UTC, comment #9: 

The part of the config.log file that you posted is the log of what autoconf does to try to determine what Fortran libraries are needed when linking Fortran with C (or C++).  The script looks at what is printed when you run the Fortran compiler to link a simple program with something like "f77 -v".  The list of libraries shown in the ld command that your Fortran compiler runs is what is parsed for the list of libraries and linker flags.  Then it tries to use the options it has discovered to link a mixed C and Fortran program using gcc instead of the Fortran compiler.  That is failing because the libraries -lfai, -lfui, -lfsu, -lsunquad, -lsunmath are not found.  The only option supplied to gcc to tell it where to find these libraries (assuming the are not in the default library search path) is -R/opt/solstudio12.2/lib.  So where are they installed?  I'm guessing that the problem is that the linker option


-Y "P,/opt/solstudio12.2/lib:/opt/solstudio12.2/prod/lib:/usr/ccs/lib:/lib:/usr/lib"


Is not being parsed correctly, and that the libraries are installed in one of those directories.  If so, then this is really a bug in the autoconf macro that does the check, not Octave.

John W. Eaton <jwe>
Group administrator
Sat 09 Apr 2011 02:04:57 AM UTC, comment #8: 

On my system, the suitesparse headers are installed in /usr/include/suitesparse.  I moved them to /app/include and ran configure with


configure CPPFLAGS=-I/app/include


and there was no problem finding amd.h or any of the other suitesparse header files.  The configure script did not stop "after looking in ${PATH}/suitesparse".

John W. Eaton <jwe>
Group administrator
Fri 08 Apr 2011 10:35:07 PM UTC, comment #7: 

FYI

/bin/sh != /bin/bash

/bin/awk != /bin/nawk

There's a long history on this sort of stuff.  There's probably a tutorial on the subject I wrote still floating around the Internet.

FWIW I spent an entire day running configure, looking at config.log, fixing the problem and moving to the next failure.

If configure were actually searching the list as stated, it should not have exited when it didn't find the header after looking in ${IPATH}/suitesparse.

I take a pretty simple approach to this sort of fubar.  Fix it and keep going.

BTW just to be clear:

I did NOT post asking for help.  It was a comment in case anyone actually cared about portability.  If anyone does, I'll help resolve it, but at this point my needs are probably better served by booting Linux, installing a binary package and doing my work.  And no, I'm not nice! Having ported largish systems from VMS to 6 flavors of Unix, I do have some idea how this stuff works.

Reginald Beardsley <rhb>
Fri 08 Apr 2011 09:12:53 PM UTC, comment #6: 


> Is Octave ANSI C++ compliant?


No, because there is no such thing, unless you mean the ancient 1998
standard, which is really ANSI/ISO. The C++ standard is currently
maintained by ISO, not by ANSI. And Octave does indeed stay pretty
close to the ISO standard (which, btw, is getting updated and the
final draft of the C++0x standard just got approved), and g++ does a
very good job of staying up to the date with the latest standard.
Indeed, a newer g++ is much closer to ISO C++ than an older one, by
far. I know of several non-standard things that older g++s accepted
for C++ that they shouldn't have. There is also a lot of C++0x that
I'm eager to use in Octave in order to simplify our code.

> FWIW Octave is the only program I would spend this much effort on.
> Anything else would have gotten an "rm -rf" after 2-3 hours unless a
> client was paying me to build it. Particularly w/ the large number
> of compiler warnings being generated.


I hate to say it, but your tone is quite aggressive, and yet you're
asking us to help you. These two attitudes are contradictory. I
recommend you either reconsider your tone or you reconsider getting
help.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Fri 08 Apr 2011 08:46:29 PM UTC, comment #5: 

 "If you want to build Octave, you are going to have to use somewhat modern tools. Sorry."


Hello!  I'm using gcc 4.4.5 which I built from source along w/ all it's dependencies.   It built all the way through stage2, so I doubt there is a problem other than whatever bugs it has. You asked what came w/ Solaris 10 and I told you.

Is Octave ANSI C++ compliant?

BTW Here's where configure dies:

ln -s /opt/solstudio12.2/prod/lib /tmp/lib_link.1302297318.10537.07
/usr/ccs/bin/ld -zld32=-S/tmp/lib_link.1302297318.10537.07/libldstab_ws.so -zld64=-S/tmp/lib_link.1302297318.10537.07/amd64/libldstab_ws.so -zld32=-S/tmp/lib_link.1302297318.10537.07/libld_annotate.so -zld64=-S/tmp/lib_link.1302297318.10537.07/amd64/libld_annotate.so /opt/solstudio12.2/prod/lib/crti.o /opt/solstudio12.2/prod/lib/crt1.o /opt/solstudio12.2/prod/lib/values-xi.o conftest.o -lm -o conftest -Y "P,/opt/solstudio12.2/lib:/opt/solstudio12.2/prod/lib:/usr/ccs/lib:/lib:/usr/lib" -Qy -R/opt/solstudio12.2/lib -t -lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk -lm -lc /opt/solstudio12.2/prod/lib/crtn.o
rm /tmp/ube.1302297318.10537.05.dbg
rm conftest.o
rm /tmp/lib_link.1302297318.10537.07
configure:28777: result:  -lm -R/opt/solstudio12.2/lib -lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk
configure:28793: checking for dummy main to link with Fortran 77 libraries
configure:28827: gcc -o conftest -g -O2 -D_REENTRANT -pthreads   conftest.c -lm    -lm -R/opt/solstudio12.2/lib -lfai -lfui -lfsu -lsunquad -lsunmath -lmtsk >&5
ld: fatal: library -lfai: not found
ld: fatal: library -lfui: not found
ld: fatal: library -lfsu: not found
ld: fatal: library -lsunquad: not found
ld: fatal: library -lsunmath: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
configure:28827: $? = 1
configure: failed program was:

Reginald Beardsley <rhb>
Fri 08 Apr 2011 08:30:09 PM UTC, comment #4: 

As requested.  Doesn't get to make.  configure falls over on the FORTRAN compiler.  F77="f90 -f77" works modulo issues w/ configure getting the link libraries wrong

I've attempted to attach the files.



(file #23150)

Reginald Beardsley <rhb>
Fri 08 Apr 2011 07:43:51 PM UTC, comment #3: 

The configure script uses the compiler to check for amd.h using the following names


suitesparse/amd.h
ufsparse/amd.h
amd/amd.h
amd.h


so if you have amd.h installed in /app/include, setting CPPFLAGS=-I/app/include should allow the compiler to find it.

I have no way of helping you find out why that is not working properly for you if you only tell me that it doesn't work/can't work/didn't work/whatever.  You will have to show precisely what is going wrong by posting the relevant parts of the config.log file.

GCC 3.4.3 is indeed too old to build Octave.  But that release is over 6 years old now.  That is absolutely ancient in the history of GCC and in particular its support for modern C++, so it is not surprising at all to me that it does not work.  If you want to build Octave, you are going to have to use somewhat modern tools.  Sorry.

You wrote:


I have observed that pieces get added to liboctinterp using a libtool executable link procedure which is not valid on Solaris for shared libraries.


I have no idea what you mean by this.  If you want help debugging the problem, you need to post precisely what you have done and precisely the error messages that you are seeing.

I suggest you try the following to build a minimal version of Octave:

  • unpack a fresh copy of Octave
  • execute the configure script with just ./configure
  • run make


If the configure script fails, post details about the specific failure.

If make fails, post details about the specific failure.

John W. Eaton <jwe>
Group administrator
Fri 08 Apr 2011 07:29:33 PM UTC, comment #2: 

I assumed you gated the mailing list to the buglist threads by subject line, but that was obviously too much.



> I'm sorry you've had a hard time building Octave, but you
> haven't really
> provided any information here to help anyone improve the
> situation.


I spent over an hour writing a more detailed description a few days earlier.  When I hit submit all that work was erased.  I had stopped for lunch which apparently resulted in my being autologged out. That and failing to enter 1984 generated an error dialog and all that work was gone.

Fool me once, shame on you.  Fool me twice, shame on me.

>
> Did you really use --with-amdincludes?  The correct
> spelling of the option is
> --with-amdincludedir.


I used --with-amdincludedir.

>
> If you have all dependencies installed in some non-standard
> place like /app,
> then you could use
>
>
> ./configure CPPFLAGS=-I/app/include LDFLAGS=-L/app/lib
>


Won't work because the configure script specifies:

#include <suitesparse/amd.h>

The standard places are not standard anyway.  Substitute /usr/local for /app and it still won't work.  The standard places are only standard on one computer.  the above is a classic example of embedding local filesystem structure where it does not belong.

>
> This is standard autoconf usage, nothing specific to
> Octave.
>
> GCC 4.5 is certainly not required.  What compiler and
> version is installed by
> default on your system?


gcc 3.4.3

I prefer using the Sun/Oracle Studio compiler suite, but post Octave 2.1.73 there was a stated requirement for gcc 4.x.  For a long time I was stuck at 2.1.73 because I didn't have time to puzzle through building gcc 4.x.  So I'm finally getting around to dealing with it.  If there is any reason to think that Octave is ANSI C++ compliant I'd be happy to try that after I sort out building it at all.

>
> If you would like to help improve the situation for your OS
> and compiler, then
> you can start by unpacking the Octave sources and running
> configure and
> reporting details about the problems you encounter.


I've got an 88 MB log file from this exercise so far.  I doubt that you really want that.  The thing that would help me is a concise statement of what objects belong in each library and how generated files are produced.

> Posting vague
> descriptions of the failures is unlikely to help solve the
> problems in future
> versions of Octave.


First I have to succeed in compiling and linking.  Even then, the problems w/ the autoconf & automake input are so severe that it will not be possible to fix it w/o the person doing the build configuration actually getting on Solaris and trying it. However, I will be able to provide a more concise explanation of the issues once I'm done.  I have observed that pieces get added to liboctinterp using a libtool executable link procedure which is not valid on Solaris for shared libraries.

NB I've built a very large chunk of the Gnu packages from source on Solaris, so it's not likely to be an autoconf or automake bug.  However, nothing else is as large and complex as Octave.  The only thing that comes close is R.

FWIW Octave is the only program I would spend this much effort on.  Anything else would have gotten an "rm -rf" after 2-3 hours unless a client was paying me to build it.  Particularly w/ the large number of compiler warnings being generated.


More later,
Reg

Reginald Beardsley <rhb>
Thu 07 Apr 2011 06:38:17 PM UTC, comment #1: 

I'm sorry you've had a hard time building Octave, but you haven't really provided any information here to help anyone improve the situation.

Did you really use --with-amdincludes?  The correct spelling of the option is --with-amdincludedir.

If you have all dependencies installed in some non-standard place like /app, then you could use


./configure CPPFLAGS=-I/app/include LDFLAGS=-L/app/lib


This is standard autoconf usage, nothing specific to Octave.

GCC 4.5 is certainly not required.  What compiler and version is installed by default on your system?

If you would like to help improve the situation for your OS and compiler, then you can start by unpacking the Octave sources and running configure and reporting details about the problems you encounter.  Posting vague descriptions of the failures is unlikely to help solve the problems in future versions of Octave.

John W. Eaton <jwe>
Group administrator
Thu 07 Apr 2011 05:50:52 PM UTC, original submission:  

FWIW

I've now spent over 30 hours trying to build 3.4.0 for Solaris 10 U8 x86 (the last freely usable release by Sun).  I have all the dependencies built and installed under /app.  This includes building gcc 4.5.0 from source with all of its dependencies.

Just getting the Octave configure to run took almost 2 days.  Mostly because of assumptions about installation of dependencies (e.g. /app/include/amd.h vs /app/include/suitesparse/amd.h)  So that even though I specified --with-amdincludes=/app/include, configure failed until I moved the headers.

The other major issue is the building of libraries.  At present, every time make fails I build the .so, .la & .a by hand and restart make. 

The cause of the failures is not clear.  It centers around trying to build shared libraries.  At the moment my guess is that some of the libraries were not built w/ the flags presumed by Octave.  I encountered several such issues building gcc.

Normally I would just write a quick shell script to do the build, but there are enough files being generated on the fly w/o any obvious documentation that I haven't tried that yet.  However, it looks as if that will ultimately be necessary.

If Octave only works w/ a particular compiler and 4 operating systems, it is hard for me to see much justification for the complexity of autoconf & automake.   Given a simple Makefile for any of OS I could quickly modify it for my environment.

Reg

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #23260:  configure.pdf added by rhb (9KiB - application/pdf)
file #23261:  build.pdf added by rhb (6KiB - application/pdf)
file #23190:  r_libtool added by rhb (266KiB - application/octet-stream)
file #23189:  octave_libtool added by rhb (262KiB - application/octet-stream)
file #23187:  libcruft_makefile added by rhb (282KiB - application/octet-stream)
file #23177:  err.log added by rhb (4KiB - application/octet-stream)
file #23150:  make.log added by rhb (29KiB - application/octet-stream - make.log is console output)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by rhb (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-16 rik5 Open/ClosedOpen Closed
    2011-04-16 rhb Attached File- Added configure.pdf, #23260
        Attached File- Added build.pdf, #23261
    2011-04-10 rhb Attached File- Added r_libtool, #23190
    2011-04-10 rhb Attached File- Added octave_libtool, #23189
    2011-04-10 rhb Attached File- Added libcruft_makefile, #23187
    2011-04-09 rhb Attached File- Added err.log, #23177
    2011-04-08 rhb Attached File- Added make.log, #23150

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code