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

[Reginald Beardsley]

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

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


    _______________________________________________________

Reply to this item at:

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

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