Tue 06 Jan 2015 06:50:25 PM UTC, comment #28:
@Philip:
My attempt to repeat to build mxe-octave in Ubuntu Desktop Linux 14.10 failed already when building BLAS library ...
I did follow the official steps mentioned here http://wiki.octave.org/MXE
Then I tried to follow your steps below and ended up with same error.
Getting always same error during make:
> Failed to build package blas!
> ------------------------------------------------------------
> Makefile:171: recipe for target 'isamax.o' failed
> make[2]: *** [isamax.o] Error 127
> make[2]: Leaving directory '/opt/mxe-octave-a5e6d54bcd60/tmp-blas/BLAS'
> /opt/mxe-octave-a5e6d54bcd60/Makefile:674: recipe for target 'build-only-blas' failed
> make[1]: *** [build-only-blas] Error 2
> make[1]: Leaving directory '/opt/mxe-octave-a5e6d54bcd60'
> real 0m1.109s
> user 0m0.328s
> sys 0m0.824s
> ------------------------------------------------------------
> [log] /opt/mxe-octave-a5e6d54bcd60/log/blas
>
> Makefile:674: recipe for target '/opt/mxe-octave-a5e6d54bcd60/installed-packages/blas' failed
> make: *** [/opt/mxe-octave-a5e6d54bcd60/installed-packages/blas] Error 1
> root@ubuntu:/opt/mxe-octave-a5e6d54bcd60#
As I am neither experienced enough with MXE nor I have time to work it out and as I already succeeded with official Octave 3.8.2 sources compilation (with small modification of one source file - /libinterp/dldfcn/amd.cc) and it works for both root and non-root users with ability to specify the lib and octave installation directory (defaulted to /usr/local) - this is for me good enough solution and I leave it to you and other MXE build experts to find out the correct way for other Linux distros.
|
Mon 05 Jan 2015 09:49:02 PM UTC, comment #27:
Slight amendment:
When running Octave from the mxe build tree, you need to start Octave with a shell script rather than with the executable itself:
otherwise the regular system bin dirs (/usr/local/bin etc.) come first in the PATH.
I suppose it's simply a matter of proper prefixing at configure time to cure this.
|
Mon 05 Jan 2015 09:15:57 PM UTC, comment #26:
@richard comment #25 (and as a confirmation that mxe --enable-64 works fine)
I've just built Octave 3.9.0+ and 4.1.0+ with --enable-64 (64-bit indexing) on Linux along the lines JWE sketched in comment #13.
It took only this:
- install all dependencies for mxe (not so much)
- do:
hg clone http://hg.octave.org/mxe-octave <your_mxe_build_dir>
cd <your_mxe_build_dir>
autoconf
./configure --enable-system-gcc --enable-64 --enable-lib64-directory --disable-jit --enable-native-build --enable-pic-flag --host=gnu-linux ## see comment #13, all on one line
- build plain 32-bit octave-3.9.0+ & 4.1.0+ dist archives (make all dist), or download 4.1.0+ from hydra
- edit <your_mxe_build_dir>/src/octave.mk to enter 3.9.0+ & 4.1.0+ (in separate runs) with the openssl sha1 checksums
- make tar-dist JOBS=9 ## or any number you see fit)
- wait (with a core i5 system ~ 1.5 - 2 hours time to do other things)
and then it's a mere matter of editing your window manager's menu and adding:
/full/path/to/<your_mxe_build_dir>/usr/bin/octave-<version> --force-gui
(+ optionally hunt down the icon in ..../usr/share/octave/<version>/imagelib)
Note that with 4.1.0+ you'll currently have to edit <mxe>/src/octave.mk and add:
--without-sndlib \
--without-portaudio \
in the EXTRA_CONFIG_OPTIONS section as the sound stuff won't build with --enable-64
|
Sun 04 Jan 2015 10:56:30 AM UTC, comment #25:
@richard (comment #24)
You've done a lot of work which at first sight shouldn't have been needed. One of the issues you correctly mention is lack of documentation.
The easiest would (should) have been to build a 64-bit Octave using mxe-octave; that would have saved you lots of work as mxe-octave builds all the required dependencies for you w. 64-bit indexing. See comment #13 in this thread.
JWE didn't tell there how to get it installed (AFAIK on Linux Octave has hard-coded paths, contrary to Windows where Octave also has hard-coded paths but relative to a relocatable Mingw/MSYS installation); but I suppose this is a matter of proper PREFIX stuff and maybe it's even easier.
That said, last week I tried this (building a Linux 64-bit idx. Octave) with mxe-octave (for bug #43908) but already at the very start I ran into issues, i.e., when building pkg-config (its configure couldn't get gcc to work). ATM I have no time/priority to sort that out sufficiently for a bug report; maybe my Linux distro is the issue here (mageia-4 64b, almost out-of-support, 4.1 is current). I'll pickup there later on.
|
Sun 04 Jan 2015 08:54:10 AM UTC, comment #24:
Not sure how much is this relevant - but maybe someone searching in this thread will find this info useful.
I did struggle a lot with compiling Octave using --enable-64 switch. The compilation of Octave source code wasn't that big of a deal - but when running make check I was getting various errors in various test scripts depending on the 3rd party libraries (ARPACK, BLAS, LAPACK, ...) I had in my Linux distribution (Ubuntu Desktop 14.xx).
Finally I made it working - it required to recompile many libraries with 64bit indexing -> more details here: https://github.com/calaba/octave-3.8.2-enable-64-ubuntu-14.04
|
Wed 12 Nov 2014 03:21:11 PM UTC, comment #23:
Closing as fixed
|
Tue 28 Oct 2014 12:19:41 PM UTC, comment #22:
Pushed changeset http://hg.octave.org/mxe-octave/rev/933b99febcf1
|
Sat 18 Oct 2014 01:48:41 PM UTC, comment #21:
You are right - I missed the default settings '-'.
OCTAVE_BUILD isnt needed, kind of just an artifact from the old rules.
Fixed all in this patch.
(file #32290)
|
Sat 18 Oct 2014 12:42:20 PM UTC, comment #20:
John D:
I haven't tested your patch, but it looks like there is some inconsistency with the definition of ENABLE_OCTAVE. The default value doesn't have a trailing dash but two of the individual settings do.
Is OCTAVE_BUILD really needed? Where is it used?
It looks like the STABLE_BUILD variable is eliminated but that would still be used in the binary-dist-rules.mk file.
|
Sat 18 Oct 2014 12:27:26 PM UTC, comment #19:
How about something like this (attached)
The --enable-stable (and --disable-stable) was allowing selection between the offical stable, and the source on the alpha site.
I have changed it to --enable-octave=xxxxxx where xxxx=alpha, stable or default (no value given defaults to stable)
The alpha and stable are the using teh sources that they already were.
default is the default sources from comment 18.
(file #32289)
|
Tue 14 Oct 2014 12:35:09 PM UTC, comment #18:
Not sure if you meant a snapshot of current stable or default, but there is a source built from default always available at http://hydra.nixos.org/job/gnu/octave-default/tarball/latest/download
|
Thu 09 Oct 2014 08:21:19 PM UTC, comment #17:
I'm not sure what to do about the gnulib isatty patch. The current src/octave.mk file in mxe-octave is using a snapshot version of octave 3.8.2, which probably does need the isatty patch. Current versions of Octave don't need that file, but there isn't a snapshot available from an ftp site either. It might be nice to modify the build system so that it can grab the current sources from hg, but I don't have time to try to make those changes now.
|
Thu 09 Oct 2014 08:14:57 PM UTC, comment #16:
I checked in a change for the qMin problem. It's a trivial change but it took two changesets because I was careless and there was a typo in the first change.
http://hg.savannah.gnu.org/hgweb/octave/rev/eb9b2160e878
http://hg.savannah.gnu.org/hgweb/octave/rev/b8ffcb88d77c
|
Mon 06 Oct 2014 07:57:43 PM UTC, comment #15:
I'll push the changes.
Yes, the fix for QtHandlesUtils should work for 32- or 64-bit indexing.
|
Mon 06 Oct 2014 06:46:31 PM UTC, comment #14:
Of course you're right, 64-bit indexing is a special setting. Building with mxe-octave is required then for --enable-64.
Does the QtHandlesUtils.cc patch also work for 32-bit systems?
The patch fixes the original cause for the failure of --enable-64 builds in my original report.
Will you push that patch or should one of us (John D. or me) do it?
|
Mon 06 Oct 2014 06:18:55 PM UTC, comment #13:
The default for most GNU/linux blas libraries (and other libraries that rely on them) is to use 32-bit indexing even on 64-bit systems like x86_64. I don't know how to tell what library has been dynamically linked from within Octave itself or how to determine whether 32-bit indexing is being used other than perhaps to try a test call to a blas function and see if it does the right thing.
In any case, I built Octave from the default branch (hg id ec037d41da06) using the mxe-octave configure command
I also had to remove the gnulib-isatty patch as it is no longer needed. And I added the following patch
Starting the resulting Octave binary and executing _run_test_suite_ produced the following results for me:
I think the skipped tests are due to disabling qhull and the jit compiler.
|
Mon 06 Oct 2014 02:31:55 PM UTC, comment #12:
@JohnD comment #9: my 4.1.0+ builds are still native on Mageia 4 Linux.
The builds with the errors in comment #7 are from IIRC "8cc4a9bb253b fullfile.m: Match documentation name to function variable name."
But a newer clone (":6443693a176f maint: Periodic merge of gui-release to default") gave the same eror.
An mxe cross-build of 4.1.0+ broke last night on the gnulib-isatty patch in mxe-octave. Tonight I'll have another try (moving the patch out of the way, wasn't it needed anymore?).
@JWE comment #11: As to the lu.cc and lsode stuff & BLAS: AFAIK I have only the x86_64 versions of the numerical libs installed through Mageia's package manager (drakinst). But I'll check a bit more rigorously tonight if a 32-bit BLAS sneaked into the 32-bit /usr/lib section through some 32-bit SW I also have installed.
Would Octave give any clue as to what bit-width libs it has been linked with, through e.g. octave_config_info?
|
Mon 06 Oct 2014 11:00:54 AM UTC, comment #11:
For the lsode problem and the crash in the lu tests is is possible that you are dynamically linking with a 32-bit blas library when the tests are executed?
|
Mon 06 Oct 2014 10:30:06 AM UTC, comment #10:
Running make check on the linux ntibve build has issues though (mint linux):
|
Mon 06 Oct 2014 10:24:30 AM UTC, comment #9:
The 4.1.0+ failure you are getting is compiling a native octave in linux, or cross compile?
If native linux, I didnt have any issue compiling with just ./configure --enable-64, using head:
changeset: 19221:f5ad7470d957
bookmark: @
tag: tip
user: Mike Miller <mtmiller@ieee.org>
date: Sun Oct 05 16:45:08 2014 -0400
summary: fftw: Reword error messages to be consistent with other functions
|
Sun 05 Oct 2014 11:32:23 PM UTC, comment #8:
ok - 3.9.0+ didn't have that issue with docs - I guess I should try compiling default on my machine
|
Sun 05 Oct 2014 06:04:51 PM UTC, comment #7:
Build error I referred to in comment #6 (+ patch attached below):
This error can be fixed using the attached changeset.
The build continues then with lots of "Division by zero"s
I think the changeset is harmless as the output arg it removes isn't used anywhere.
(file #32227)
|
Sun 05 Oct 2014 03:35:43 PM UTC, comment #6:
Ok, with your patch octave-4.1.0+ builds with --enable-64.
I had to specify --enable-docs=no to avoid an error with (IIRC) qr expecting an integer < some limit (I have to configure/build again to recover that exact error, will do later tonight; the successful build ran while I was away this afternoon).
"make check" crashes in l.cc-tst:
As to the OF packages:
in mxe-octave, after the patch I submitted in bug #43318, the following packages in mxe-octave still won't build with 64-bit Octave:
- image
- odepkg
- fl-core
- netcdf
|
Sun 05 Oct 2014 11:52:50 AM UTC, comment #5:
In the past, I have created patches for mxe-octave and used them until the of-package gets released with the fixes.
Currently sockets and fl-core still do this.
https://savannah.gnu.org/bugs/?41214
https://savannah.gnu.org/bugs/?41086
|
Sun 05 Oct 2014 10:13:14 AM UTC, comment #4:
Thanks, I'll try later today with a 4.1.0+ build.
Your patch (a cast at the location of the actual compile error) suggests that the OF packages that won't install on 64-bit Octave (Linux or Windows or OSX) have to be patched individually as well for each individual compile error.
Would that be a job for the package maintainers, or should/could the mxe-octave developers provide patches for OF packages to be included in mxe-made installers?
I tend to opt for the former.
|
Sat 04 Oct 2014 10:21:17 PM UTC, comment #3:
Patch attached that worked for me, to compile 3.9.0+, gui-release
(file #32223)
|
Fri 03 Oct 2014 08:09:06 AM UTC, comment #2:
(Thanks for having a look)
Yes only in 64-bit.
As to the error messages I have to more precise:
the compile errors do not refer to functions proper but to function arguments that have no unambiguous resolution (and thus implicitly point back to functions handling those arguments).
In octave-4.1.0+ it is arguments to QMin() (see verbatim in my OP), while in e.g., the image package I see:
("pkg install -forge -verbose image" in Octave-3.8.2 64-bit)
...which all seem to point to the issue that some conversions that work in 32-bit don't work in 64-bit.
Coincidentally I was just looking into octave-dev (the QMin error) and found that QMin is probably a Qt function. Qt obviously has been built for 64-bit as well so it may well expect some other <int> types that the "int" it gets from Octave in QtHandlesUtils.
AFAICS all these errors I hit with --enable-64 in octave-dev and some OF packages, seem to refer to conversions from some lower rank <int> type to some other <int> type, usually long or long long int.
That gives me the the vague hope that it might just be a missing #include or some missing conversion template(s) in a core Octave header file.
But for the same token the conversions/templates may need to be
emplaced on a case-by-case basis. That would be a lot more work.
My C++ knowledge, especially the overloading & template stuff, is lacking so it may be just a shot in the dark.
|
Fri 03 Oct 2014 05:38:28 AM UTC, comment #1:
Using gui-release
changeset: 19181:e85203f41402
branch: gui-release
user: Torsten <ttl@justmail.de>
date: Sun Sep 28 17:30:38 2014 +0200
summary: set cursor color of the editor to color of default text (bug #43314)
It compiles ok for me in 32 bit mode - its only an issue in 64 bit?
|
Sun 28 Sep 2014 05:43:42 PM UTC, original submission:
Not only the dev version (4.1.0+) but also gui-release (3.9.0+).
The offending code is in QtHandles.
FWIW I see more or less the same error ("no matching function for..." ...some call to a function with int* argument) when trying to install some OF packages (image, odepkg) in Octave 3.8.2 built with --enable-64.
|