bugGNU Octave - Bugs: bug #47183, Problems with instructions on...

 
 

bug #47183: Problems with instructions on http://wiki.octave.org/MXE - and suggested improvements

Submitter:  Michael Maloney <jacotot>
Submitted:  Wed 17 Feb 2016 10:30:21 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Fixed Assigned to:  None
Originator Name:  Mike Maloney Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 29 Mar 2016 05:42:17 PM UTC, comment #7: 

It seems like this bug has been addressed in the wiki.

If not, the best place to do this is actually on the wiki, not in a bug report.

Mike Miller <mtmiller>
Group Member
Thu 18 Feb 2016 09:17:12 PM UTC, comment #6: 

Thanks for all the feedback - the comment about 16bit graphicsmagick soon becoming the standard on Debian (And then Ubuntu) is good news indeed!

One thing I didn't say before, but which I would like to say now is...

a big thank you to you and others for putting the work into making these kind of things available. Because of the mxe-Octave windows procedure I now have a 64 it version of Octave configured with with 16bitgraphicsmagick, and I've learnt how to use a similar preocedure for Linux versions. I would not have been able to do any of this without all the effort that went into creating them in the first place. What I've posted here is by way of, in a very small way, making a contribution to that work.





Michael Maloney <jacotot>
Thu 18 Feb 2016 09:02:13 PM UTC, comment #5: 

I too have been using my own builds of Octave because of GraphicsMagick. You have a page on our wiki with instructions for it

http://wiki.octave.org/GraphicsMagick

which has all the dependencies needed for it. You can then use our page for instructions on Debian based distributions

http://wiki.octave.org/Octave_for_Debian_systems

By the way, Debian testing has finally changed their default quantum depth for Graphicsmagick  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557879#141 so you won't have that problem once it gets to Ubuntu.

Carnë Draug <carandraug>
Group Member
Thu 18 Feb 2016 08:43:33 PM UTC, comment #4: 

For what you want to do, I would probably just build my own copy of the GraphicsMagick library and then build Octave using the usual untar, bootstrap, configure, make steps.  Running it might require setting LD_LIBRARY_PATH to pick up the correct GraphicsMagick library, but it seems to me that would be better than building all dependencies, including a new GCC toolchain all from scratch.

The reason I modified mxe-octave to allow native builds on unixy systems was so that I could build Octave for systems that have obsolete versions of GCC and other dependencies.  But if your system has a reasonable set of tools, building all of these things instead of using the packages provided by the system is probably not the best thing to do.  I added some info to the wiki page.  I didn't write the original version of that page, but I'm sorry if it was misleading.

John W. Eaton <jwe>
Group administrator
Thu 18 Feb 2016 07:44:05 PM UTC, comment #3: 

Re problems with crashes: I started things off in each case with clean sweep of everything, before restarting any make steps, so I don't think this was the problem. I only used restarts for a specific configuration - wiping things completely if I decided to run configure again. At this point I'm not using the 64 bit addressing.

The reason I'm not using the ppas to install a binary is that the default quantum-depth used with graphicsmagick is 8bit and I need a version of Octave with built with a 16 bits version  graphicsMagick.

I do want a stable version - and in each case that is what I have built, either via the standard configure and make approach - or via the mxe approach.

I have done this using the method of downloading the source and then running configure etc to build and install Octave - and get a 16 bit version this way (after downloading and building GraphicsMagick as a 16 bits version).

The reason I looked at the MXE procedure was that I also needed a 16 bit image version of 64bit Octave for Windows, and was able to do this via the mxe-Octave method for Windows.

I thought then it might be useful to get familiar with the mxe  procedure for a linux build.

I'm not an expert on this stuff and ended up spending a fair amount of time to get things working with the mxe-Octave Linux version. By posting the details here I hope at least to make things easier for others until such time as any changes do get made to the procedure.

Thank you for looking at this.

Michael Maloney <jacotot>
Thu 18 Feb 2016 12:24:13 AM UTC, comment #2: 

The answer to jwe's question is no, we have people routinely building Octave (both stable and development) on 14.04.

I don't use mxe-octave for native builds, but presuming that that's what the OP intended, worth investigating if there are any missing pieces.

OP: if you are just looking for a way to have an up-to-date Octave on 14.04, and not necessarily using mxe-octave, are you aware of the PPAs for installing binary packages of either a current stable or development version of Octave?

https://launchpad.net/~octave/+archive/ubuntu/stable
https://launchpad.net/~dac922/+archive/ubuntu/octave-unstable

Are you also aware of the instructions for building Octave from source for your system that does not make use of mxe-octave?

http://wiki.octave.org/Octave_for_Debian_systems

Mike Miller <mtmiller>
Group Member
Wed 17 Feb 2016 11:04:40 PM UTC, comment #1: 

Are the tools on Ubuntu 14.04 so old that you actually need mxe-octave?

Did you configure with --enable-64, perform part of the build, then reconfigure without that option and start the build from where you left off?  That could explain the crash, as it could mean that you are mixing some libraries built for 64-bit indexing with a version of Octave that is not using 64-bit indexing.

John W. Eaton <jwe>
Group administrator
Wed 17 Feb 2016 10:30:21 PM UTC, original submission:  

I tried using the steps outlined on the wiki for building Octave on my Ubuntu 14.04 x64 system.

The following used mxe-octave-0c3b6061a202.tar.gz to create the starting mxe-octave folder for the build

I encountered two problems

PROBLEM 1

At the gnutls build step it failed saying it couldn't find Nettle 2.7.1. From googling this I found that the configuration step needed the following feature added.


--enable-lib64-directory


Also I saw a warning message saying that --enable-64 was for enabling WINDOWS 64 - so I removed this from the confguration list.

My final configure step wasa as follows:


 ./configure --enable-native-build --enable-pic-flag host_alias=gnu-linux --enable-openblas --enable-jit --enable-lib64-directory


*PROBLEM *2
The build failed at the curl step because it was trying to link against librtmp. On my system this is a static library. When I realized how many things were hanging off this library I decided not to mess with this (part of the regular Ubuntu instal).

Instead I downloaded a copy of rtmpdump to a location outside of my mxe-octave folder using


git clone git://git.ffmpeg.org/rtmpdump


I then modifed the make file for this to add -fPIC to the CFLAGS entry, giving the following line


CFLAGS=-Wall $(XCFLAGS) $(INC) $(DEF) $(OPT) -fPIC


I then ran make to buildthis and copied the folowing files from this folder into my mxe-octave/user folder
   * create folder /mxe-octave/user/include/librtmp
   * place copies of amf.h, http.h, log.h, rtmp.h into this
   * copy librtmp.a librtmp.so librtmp.so.1 into
     mxe-octave/usr/lib

Curl then builds without any problems. The file librtmp.so is a shortcut, so it might need recreating to point at the version of libtmp.so.1 in /mxe-octave/usr/lib.

By making those two changes the build procedure ran perfectly for all other steps, and Octave started without problem.

I ran the test suite in batch by


./octave --no-gui
__run_tst_suite__


This stopped at geometry/voronoi.m with panic: Segmentation fault
I haven't had a chance to look a that yet.

One further suggestion I would make is that for the step where you change to usr/lib to do the mv of libblas and creating the link for libopenblas it is VERY EASY to inadvertently type /usr/lib. I did this and the first clue I had done this was my move command failed because I wasn't authorized - at which point I realized I had jumped to a totally different folder.

As some users want a version of Octave that runs with 16bit version of GraphicsMagick, it might also be worth pointing out that this can be set up before running mak by edding  mxe-octave/src/graphicsmagick.mk and adding the line


--with-quantum-depth=16 \


if 16 bit is required, or change this to 32 above if that version is required.
 
In summary
1. I would suggest using the following configuration step to ensure gnutls (and maybe other steps), build without problem on 64 bit systems - or at least provide alternatives and an explanation of which to use.


./configure --enable-native-build --enable-pic-flag host_alias=gnu-linux --enable-openblas --enable-jit --enable-lib64-directory


2. Consider adding a librtmp.mk step to the overall mxe-octave procedure that builds a version with a CFLAG setting -fPIC to avoid any problems when building curl.

3. Highlight the point about changing the graphcsmagick quantum-depth setting before building.

4. Sound a warning about accidentally dropping into /usr/lib instead of being in /mxe-octave/usr/lib!

I'm not an expert on this stuff, so thelibrtmp bit is something of a work round, and needs a proper solution.

Michael Maloney <jacotot>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jacotot (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-29 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code