Re: Trying to compile Octave on RHEL 7.3

[Michael Metts]

So I downloaded 4.2.1 from the ftp site and built it.  the build was clean but 
when i say ./run-octave get a command window that’s full of black dots.  when 
type, the characters are invisible.  if i press enter, the command is executed 
and appears in the command history pane but the command window itself is just a 
sea of black dots.  if i clear it, i can see the cursor to the top but all the 
dots are just as they were.  so close and yet so far.  i’ll run the make tests 
but i wonder if there’s something else i’m missing here.

> On Mar 2, 2017, at 10:26 AM, Mike Miller <address@hidden> wrote:
> 
> On Thu, Mar 02, 2017 at 10:02:51 -0800, Michael Metts wrote:
>> ok.  i’m doing a test build now.  i’ll download 4.2.1 and try the same
>> techniques on that.  i looked at the Sundails site the other day and
>> like Ozzy suggested it looks as though the Sundails I have from EPEL
>> was compiled without the IDAKLU switch … even though i thought i read
>> that it was the default.  i was tempted to build Sundials myself but
>> maybe i’ll leave well enough alone at this point.
> 
> I think you're right, I have the log file you sent also, and it looks
> the same as on my distribution (Debian testing), the sundials IDA
> library is available, but IDAKLU is not. This is a fairly new feature in
> both sundials and in Octave, so still shaking out.
> 
>> i would like to help out but i’m so terribly green at build/make and
>> such.  it’s been years since i actually programmed in C or C++ … or
>> even Fortran so i’d be embarrassed at the results i’d get with any
>> serious mucking about with a build such as this.
>> 
>> i would be open to being an ignorant build tester, though.  we are
>> likely to focus on RHEL and AIX here at my firm indefinitely.  we have
>> a lot of PhD, Finance and Econ folks that want and expect Matlab … but
>> we’d rather not run it on RHEL.  it’s expensive enough on Windows.
>> it’s possible that some RHEL Octave build here could become “mission
>> critical” for some analysis in the future.  but for now, it’s more
>> about showing/proving that this is a great or “good enough”
>> alternative and the 48-core RHEL system will lure them in.
>> 
>> thanks for all your help.  with the above in mind, let me know what
>> you recommend re: me participating.  
> 
> If you're willing to do occasionally build tests of the dev branch on
> your RHEL+EPEL setup, I think that would be helpful to catch errors that
> might otherwise go unnoticed until after a release. When I used to have
> daily access to RHEL 5 and 6 at work, I would do this kind of occasional
> build testing to make sure everything still works.
> 
> Even better would be a RHEL+EPEL system that could run a continuous
> build script and integrate with our CI system
> (http://buildbot.octave.org:8010/). We have plenty of Fedora and Debian
> coverage, but we have not had anyone volunteer a CentOS or RHEL system
> yet.
> 
> -- 
> mike