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

 
 

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

Submitted by:  Michael Maloney <jacotot>
Submitted on:  Wed 17 Feb 2016 10:30:21 PM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Installation Failure
Status: FixedAssigned to: None
Originator Name: Mike MaloneyOpen/Closed: Closed
Release: 4.0.0Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
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>
Project 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>
Project 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>
Project Administrator
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>
Project 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.

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:

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

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

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

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

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.

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by jacotot (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 29 Mar 2016 05:42:17 PM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1