Re: How can I build Octave without debugging symbols? (What is the "official" method?)

[Jordi Gutiérrez Hermoso]

On 18 May 2012 21:56, irrational John <address@hidden>
wrote:
> Apologies if this question is inappropriate here. I honestly just
> did not know where else to ask it. I did ask on the help-octave
> mailing list a month ago, but got no response at all.

Normally this should go in the help list, but I guess today is the day
for having discussions on the dev list about building Octave.

> Because the version of Octave installed from the Ubuntu repository
> is somewhat older (v3.2), I have been experimenting with building
> Octave from the source code using the commands below.
>
>> ./configure
>> make
>> make check
>> make install
>
> This went mostly fine for me except that it seemed to require a
> build directory of nearly 2GB?!?

Yes?!? I believe so?!? Perhaps you should update this part of the FAQ:

    http://octave.org/wiki/index.php?title=FAQ#Installation_issues_and_problems

> Eventually I stumbled across the comment below in appendix G.2 of
> the Octave documentation.
>
>> Octave requires approximately 1.4 GB of disk storage to unpack and
>> compile from source (significantly less, 400 MB, if you don't
>> compile with debugging symbols). To compile without debugging
>> symbols try the command

>>          make CFLAGS=-O CXXFLAGS=-O LDFLAGS=

>> instead of just make.
>
> OK, fine. The only problem is that this direction does not work. Or
> at least it did not work for me.

Yes, I am not sure what brought about this change, but it looks like
your assessment that you need to do this with ./configure and not make
is correct. I thought earlier versions of Octave did allow you to pass
the flags to make, but I suppose this is no longer true.

I can make it work this way if I pass flags through the internal
CONFIGURE_CXX and CONFIGURE_C flags. Perhaps libtool is interfering
here.

> Is it possible that the documentation is just wrong?

Of course.

> But I was just guessing when I did this. I do not know if this
> method is "safe".

Yeah, it's fine.

> I  also am curious if using other options to increase the level of
> optimization might be known to cause problems.

Well, try it and see. -O3 enables some options that may be undesirable
because they can significantly increase code size, which seems to be
something you don't want. I think I tried an -O3 build once and didn't
see a considerable speedup. Try timing the test suite at each
optimisation level to compare and make sure no semantics were changed.

HTH,
- Jordi G. H.