bugGNU Octave - Bugs: bug #44998, [MXE] On Windows side, 64-bit OF...

 
 

bug #44998: [MXE] On Windows side, 64-bit OF modules can be miscompiled

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sat 02 May 2015 12:30:20 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  lostbard
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * other Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 09 Jul 2015 12:45:11 AM UTC, comment #47: 

Closing as fixed

John Donoghue <lostbard>
Group Member
Sat 04 Jul 2015 08:37:17 PM UTC, comment #46: 

I can confirm that csv2cell does work fine now with a 64-bit Octave, after installing io-2.2.8 using "pkg install -forge"

I haven't been able to try the windows package as it somehow didn't get "installed" in the binary installer.
Plus, I think I need to rebuild an mxe installer w/o --enable-binary-packages flag

Philip Nienhuis <philipnienhuis>
Group Member
Fri 03 Jul 2015 11:20:46 AM UTC, comment #45: 
John Donoghue <lostbard>
Group Member
Thu 02 Jul 2015 06:00:10 PM UTC, comment #44: 

Compiling the native gcc as static makes the compiler work for native compiling.

With it, both  win32 and 64 work once again.

See patch

(file #34363)

John Donoghue <lostbard>
Group Member
Fri 05 Jun 2015 02:32:06 PM UTC, comment #43: 

It is needed just for nsis, unless we can patch nsis enough for 64 bit build.


John Donoghue <lostbard>
Group Member
Fri 05 Jun 2015 01:38:58 PM UTC, comment #42: 

IIRC all we use multilib gcc for is 32-bit nsis to be used with 64-bit Octave installers, isn't it.

Anyway, what needs to be done now?

- Again switch to gcc-5.1.0, in spite of JWE's wish?

- Or can we use ready-baked binary 32-bit nsis (that is, not built in mxe-octave) just like e.g., zip / unzip?

These days I cross-build my 64-bit Octaves with gcc-5.1.0 anyway, AFAICS all works fine incl. odepkg, windows and io.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 05 Jun 2015 12:05:49 PM UTC, comment #41: 

I back tracked gcc to be NOT multilib for a mxe compile and built without the installer and tried it.

I don't see any issues running a native compiled io with it, so it appears to me that there is an issue with the multilib created version of gcc 4.9.2.

Whatever the issue is/was it must have been fixed in gcc 5.1.0.


John Donoghue <lostbard>
Group Member
Wed 27 May 2015 05:59:18 PM UTC, comment #40: 

As to bug #45039, AFAIU that refers to the host's build chain (Linux gcc) that is used to build the cross-compiler. On my Linux system (Mageia-4) that build goes straight trough, so maybe there is an incompatibility problem on the Ubuntu side (note: I don't say "bug").

Back to topic:
I do not fully trust the gcc compiler(s - both cross and cross-built native). I've put cout statements after almost every statement in csv2cell.cc, all variable values thus echoed to the screen look valid, and the next statement (completely valid c++ syntax) crashes the application. The fact that the same code works well with another compiler version gives a very itchy feeling.

A while ago I tried to look back in Octave's own log to see when the change happened that provoked these crashes. It must have happened somewhere before the time that gui-release and default were merged; a few weeks before that moment these problems didn't occur. OK, gui-release (3.9.0+) was required to build some OF packages but they did run fine in default (the then 4.1.0+) in my dual-version MXE builds (patch #8469). IOW, somewhere earlier in the (then) 4.1.0+ branch something happened that hampered building OF packages.

Maybe it is time to re-attempt a native build on MinGW (using e.g., 4.9.2) to check if the cross-compiler is reliable.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 27 May 2015 04:46:43 PM UTC, comment #39: 

Perhaps a clue, if I create a c++ source file testc.cpp:


#include <iostream>
#include <string>

int main()
{
        std::string s = "hello";

        return 0;
}


And in octave:
mkoctfile testc.cpp --link-stand-alone -v -o testc
And then:
exec('testc')

It crashes.

I have a bat file for opening a terminal  window in the octave environment:

set OCTAVE_HOME=c:\octave\octave-4.0.0-rc4
set PATH=%OCTAVE_HOME%\bin;%PATH%
%OCTAVE_HOME%\bin\bash.exe


If I run that, and then run the program I created in octave from within bash, it does NOT crash.

John Donoghue <lostbard>
Group Member
Wed 27 May 2015 04:31:01 PM UTC, comment #38: 

Well the 'good' news is that a fresh build on fedora box also crashes as your comments.

binary packages appear to work ok, select native built packages have issues.

John Donoghue <lostbard>
Group Member
Wed 27 May 2015 10:38:05 AM UTC, comment #37: 

5.1.0 had  build issues for some per https://savannah.gnu.org/bugs/?45039

So 4.9.2 has issues with x86_64
5.1.0 has issues with i686.

I left a build going last night so will give mine a go and see if it can be made to have the same problem or works ok for me.


John Donoghue <lostbard>
Group Member
Wed 27 May 2015 06:07:32 AM UTC, comment #36: 

Just to clarify, I built the gcc-4.9.2 version without the --enable-binary-packages flag.
I the gcc-5.1.0 version, I installed the io and windows package from the /src/ subdir of the gcc-4.9.2 version (so they have no prebuilt .oct files). IOW I tested the compilers on the Windows side.
My conclusion is that sticking to gcc-4.9.2 doesn't not look like a wise idea.
Should we discuss this on the maintainers ML?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 26 May 2015 08:01:40 PM UTC, comment #35: 

Yesterday evening I've built with a 4.1.0+ tip with a fresh mxe-octave clone using --enable-windows-64.
I'm sorry to report that the very same problems still exist:

csv2cell (<csv file>)  => crashes Octave

app = actxserver ("Excel.Application")
app.Quit()    => crashes Octave


Later on I rebuilt the same Octave tip with mxe-octave w. gcc-5.1.0 (+ all patches since then except the gcc backout applied manually). Result:

works fine.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 May 2015 09:14:20 PM UTC, comment #34: 

I tried the new odepkg and it appeared to work ok for me both cross compiled and compiled by doing a -forge install.

The latest mxe as of friday had it updated to the new package.
I will try that function.

I was pretty sure i had some incompatability with java -but hadnt bothered with  working out what the issue was yet :)

John Donoghue <lostbard>
Group Member
Sun 24 May 2015 09:50:34 PM UTC, comment #33: 

Did you also try to run csv2cell in the io package? that also was one of the miscompiled functions with --enable-windows-64. It doesn't require Java.
Be sure to try .csv files with and without headerlines.

(Just a WAG) Java incompatibilities may comprise Octave having been built with a 32-bit JDK but running on the Windows side with a 64-bit JDK (or vice versa).
Hint: it is very well possible to have both a 32 and a 64 bit JRE installed in Windows.

odepkg has a new release, did you try that one?

It would be very nice if this miscompile issue were fixed. Seems it's a bit enigmatic why it happened, as well as enigmatic why it apparenty disappeared.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 09 May 2015 08:07:25 PM UTC, comment #32: 

I rebuilt with 4.9.2, default-octave, windows-64, enable-binary-packages and the windows package runs without crashing for me.

.m files in C:\Octave\Octave-4.0.0-rc3\share\octave\packages\windows-1.2.1

.oct files in C:\Octave\Octave-4.0.0-rc3\lib\octave\packages\windows-1.2.1\x86_64-w64-mingw32-api-v50+


io fails due to java incompatibilities, as does a couple of other packages that rely on java, so I haven't tested them

Other packages appear to have around the same pass/failures (good or bad), as 32bit mode testing with the exception of octcdf with complains about wrong arg type in its tests, and optim that just crashes octave.

John Donoghue <lostbard>
Group Member
Fri 08 May 2015 08:19:06 PM UTC, comment #31: 

Both as binary package and d/led from Octave-Forge (-forge).

Only the m-files got installed (see comment #28)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 May 2015 12:42:48 PM UTC, comment #30: 

When built as a binary package it worked though?

If so, there is some difference in the binaries when compiled via cross compile vs native compiler

Just have to work out what that is :)

John Donoghue <lostbard>
Group Member
Fri 08 May 2015 12:31:02 PM UTC, comment #29: 

Upon closer look, 5.1.0 didn't help - binary parts of pkgs get installed only partially or not at all; affects also windows and image.

So we need a better solution for the 64-bit versions than a 32/64 host and 64-bit native compiler, isn't it?
If that is the underlying issue; it looks like it but I am not sure.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 May 2015 12:21:57 PM UTC, comment #28: 

Well, gcc-with 5.1.0, csv2cell did compile & run fine using "pkg install -forge io". So that part seems to have been solved.

The (mxe-rebuilt) windows pkg doesn't install completely with a "win32api.oct is not a complete file name" message and the binary subdirectory in lib/octave/<arch-api> does not exist.


Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 May 2015 10:22:42 AM UTC, comment #27: 
John Donoghue <lostbard>
Group Member
Wed 06 May 2015 03:35:48 PM UTC, comment #26: 

image doesn't compile for me in either native or cross builds for win64, using --enable-windows-64.

Not sure if that's a compiler issue or something else, but at least it is consistent.

John Donoghue <lostbard>
Group Member
Wed 06 May 2015 02:47:51 AM UTC, comment #25: 

I believe -enable-64 sets --enable-64 in octave AND enables 64 bit compiler etc (--enable-windows-64)

--enable-windows-64 just enables the 64 bit compiler

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 07:45:14 PM UTC, comment #24: 

With JOBS=3 the build seems to go smooth (now at qt) except for -as always- libmng
I have 4 cores (i5) but usually oversaturate them (7 or 9 JOBS).
Even then the system remains reasonably responsive.

OF-image did cross-compile OK (AFAICS that is) in a build from some days back, but OK i haven't tried it out on Windows.

64-bit - is that --enable-windows-64 or --enable-64 ?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 07:31:33 PM UTC, comment #23: 

A couple on the of packages don't cross compile when 64 bit mode - image being one of them. But the build script doesn't check whether it built ok, so creates a package with all the oct files, which then will install ok in windows (not knowing it is missing files)

I better fix that too :)

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 05:14:04 PM UTC, comment #22: 

I tried another rebuild with new repo and still ok, using JOBS=9, although I only have 8 cpus on this machine.
Can you try with a smaller JOBS ?

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 04:30:11 PM UTC, comment #21: 

Well doesn't look too different from my compile until it fails.
Im running fedora at the moment, but compiled it last night on mint Linux a well.

For fedora, gcc version 4.8.3. I usually run JOBS=1 and leave it running, but this morning was JOBS=4.

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 04:10:24 PM UTC, comment #20: 

Yep, same as comment #9 (BTW I see no typos there), build-gcc log attached (zipped)

(file #33928)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 03:31:42 PM UTC, comment #19: 

Same configure options as comment 9?
Can you attach or email me the full log file?

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 03:27:45 PM UTC, comment #18: 

Thanks, building now gets past isl and ends -apparently, have yet to test- successfully.

In the mean time I've made cloned a fresh mxe-octave repo and that fails consistently as follows in build-gcc:

-DBASEVER="\"5.1.0\"" -DDATESTAMP="\"\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\"\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"<http://gcc.gnu.org/bugs.html>\"" -o build/version.o /home/philip/devel/oct
dev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/version.c
gawk -f /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/opt-gather.awk /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/ada/gcc-interface/lang.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/fortran/lang.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/go/lang.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/java/lang.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/lto/lang.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/c-family/c.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/common.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/config/fused-madd.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/config/i386/i386.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/config/i386/cygming.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/config/i386/mingw.opt /home/philip/devel/octdev/mxe/mxe32_20150505/tmp-build-gcc/gcc-5.1.0/gcc/config/i386/mingw-w64.opt > tmp-optionlist
/tmp/ccuq23Lz.s: Assembler messages:
/tmp/ccuq23Lz.s:6: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:6: Error: junk at end of line, first unrecognized character is `p'
/tmp/ccuq23Lz.s:7: Warning: .size pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:7: Error: junk at end of line, first unrecognized character is `p'
/tmp/ccuq23Lz.s:11: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:11: Error: junk at end of line, first unrecognized character is `v'
/tmp/ccuq23Lz.s:12: Warning: .size pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:12: Error: junk at end of line, first unrecognized character is `v'
/tmp/ccuq23Lz.s:17: Warning: .type pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:17: Error: junk at end of line, first unrecognized character is `b'
/tmp/ccuq23Lz.s:18: Warning: .size pseudo-op used outside of .def/.endef ignored.
/tmp/ccuq23Lz.s:18: Error: junk at end of line, first unrecognized character is `b'
/tmp/ccuq23Lz.s:24: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccuq23Lz.s:95: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccuq23Lz.s:164: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccuq23Lz.s:174: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccuq23Lz.s:176: Warning: unknown section attribute 'M'
/tmp/ccuq23Lz.s:176: Warning: unknown section attribute 'S'
/tmp/ccuq23Lz.s:176: Error: junk at end of line, first unrecognized character is `,'
/tmp/ccuq23Lz.s:192: Error: junk at end of line, first unrecognized character is `-'
Makefile:2429: recipe for target 'build/version.o' failed
make[3]: *** [build/version.o] Error 1
make[3]: *** Waiting for unfinished jobs....


My host gcc version is 4.8.2 (Mageia-4 64bit)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 02:15:04 PM UTC, comment #17: 

This patch should fix isl

(file #33921)

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 11:52:14 AM UTC, comment #16: 

Can you attach the isl log?

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 11:48:47 AM UTC, comment #15: 

--enable-windows64 in comment 9 a typo?

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 11:31:30 AM UTC, comment #14: 

Never mind comment #13, sorry.
User error :-)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 11:15:31 AM UTC, comment #13: 

After a fresh mxe clone I see this:

[philip@deskprn mxe_20150505]$ autoconf
error: you must have libtool 2.2.2 or a more recent version
configure.ac:52: error: possibly undefined macro: AC_SUBST
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:68: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:73: error: possibly undefined macro: AM_SILENT_RULES
configure.ac:77: error: possibly undefined macro: AC_DEFINE
configure.ac:166: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:304: error: possibly undefined macro: AC_MSG_NOTICE
configure.ac:335: error: possibly undefined macro: AC_MSG_CHECKING
configure.ac:336: error: possibly undefined macro: AC_PREPROC_IFELSE
configure.ac:336: error: possibly undefined macro: AC_LANG_SOURCE
configure.ac:342: error: possibly undefined macro: AC_MSG_RESULT
configure.ac:446: error: possibly undefined macro: AC_LANG_PUSH
configure.ac:448: error: possibly undefined macro: AC_LANG_POP
configure.ac:732: error: possibly undefined macro: AC_CACHE_CHECK
configure.ac:759: error: possibly undefined macro: AC_CHECK_FUNCS
configure.ac:835: error: possibly undefined macro: AC_CHECK_HEADER
configure.ac:2260: error: possibly undefined macro: AM_PROG_CC_C_O
[philip@deskprn mxe_20150505]$ libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996


so apparently something is mixed up.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 11:00:45 AM UTC, comment #12: 

Oh, cs from the bug report #comment #5

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 10:59:55 AM UTC, comment #11: 

Cross-building on Mageia-4 Linux.
I believe it is isl that fails (as I see log/isl showing the error)
Otherwise clean repo, updated with hg update -C

[OT]
BTW I still have the libmng build error on my fast PC I reported a while ago, at libmng I always have to restart the build by retrying a few times with ...JOBS=1 until it continues with dbus (at which point I Ctrl-C and can continue with ...JOBS=9). From a previous log (one of those ... JOBS=1 tries):

:
make[2]: Entering directory '/home/philip/devel/octdev/mxe/mxe32_20140501/tmp-libmng/libmng-2.0.2'
/bin/sh ./libtool --tag=CC   --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.   -I/home/philip/devel/octdev/mxe/mxe32_20140501/usr/x86_64-w64-mingw32/include  -g -O2 -c -o libmng_callback_xs.lo libmng_callback_xs.c
libtool: Version mismatch error.  This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.
Makefile:409: recipe for target 'libmng_callback_xs.lo' failed
make[2]: *** [libmng_callback_xs.lo] Error 63
make[2]: Leaving directory '/home/philip/devel/octdev/mxe/mxe32_20140501/tmp-libmng/libmng-2.0.2'
/home/philip/devel/octdev/mxe/mxe32_20140501/Makefile:728: recipe for target 'build-only-libmng' failed
make[1]: *** [build-only-libmng] Error 2
make[1]: Leaving directory '/home/philip/devel/octdev/mxe/mxe32_20140501'


I think that actual error could be misleading, I rather think of some race condition. I usually build on a core i5 desktop with a fairly fast SSD. On my alternative build box (a core i5 laptop with "legacy" HDD) this build failure never happened.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 May 2015 10:22:06 AM UTC, comment #10: 

Worked for me both for win32, and 64, but will check again.

that for gcc-isl, or isl ?

From the pushed changset, changeset from this bug, or hand modified?

from clean repo or partial rebuild?

John Donoghue <lostbard>
Group Member
Tue 05 May 2015 07:56:58 AM UTC, comment #9: 

with --enable-windows64 --enable-binary-packages I get:

:
  CC       isl_vec.lo
  CC       isl_version.lo
  CC       isl_vertices.lo
  CCLD     libisl.la
libtool:   error: can't build x86_64-w64-mingw32 shared library unless -no-undefined is specified
Makefile:1148: recipe for target 'libisl.la' failed
make[4]: *** [libisl.la] Error 1
:


Philip Nienhuis <philipnienhuis>
Group Member
Mon 04 May 2015 11:00:27 PM UTC, comment #8: 
John Donoghue <lostbard>
Group Member
Mon 04 May 2015 08:12:04 PM UTC, comment #7: 

This way even if someone installs from forge it will still work.


I tried a nuild for 32bit and it appears good too, so I will push the change up later today.

John Donoghue <lostbard>
Group Member
Mon 04 May 2015 07:57:35 PM UTC, comment #6: 

Windows package (_COM_.oct) and csv2cell (io pkg) did already work fine with the cross-compile trick.
But this is good news. I already suspected the compiler.

I'll try a new build as well, overnight.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 04 May 2015 12:12:25 PM UTC, comment #5: 

Back to the original bug ...

Patch attached that updates the compiler to 5.1.0, which appears to fix the issue for win64.

At least no more crashes with instrument control or windows!

I have yet to rebuild for win32 and a native Linux mxe to verify they still compile.




(file #33894)

John Donoghue <lostbard>
Group Member
Sat 02 May 2015 04:48:28 PM UTC, comment #4: 

You're right, generating the doc cache is a little stumbling block.

But can it be done afterwards, as one of the last steps during installation in Windows?
After all, as a last OF packages install step it is also required to have Octave silently run "pkg rebuild" to update the share/octave/octave_packages file. At least, that is the easiest way to generate/update it.
AFAIK there's a helper script for pkg.m that generates the docs for an OF package.

Processing preinstall.m and postinstall.m for some of the packages may also be challenging.

As Octave can't be "cross-run" in mxe-octave, some steps for some packages just have to be done during installation on Windows.
I see little harm in running a "headless" Octave to stitch together some final missing pieces during installation on Windows.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 May 2015 03:27:11 PM UTC, comment #3: 

I had started a script that would do a full install of a package in the cross build.

The pending parts I hadnt tackled were:
- building any docs based on the sources.
- updating the package list file with the new package as installed.

Updating the list file should be easy - I hadnt looked anough at how to generate docs to decide how best to do that.


John Donoghue <lostbard>
Group Member
Sat 02 May 2015 03:11:33 PM UTC, comment #2: 

You thought the right thing, your trick works!

It won't work for OF package upgrades nor for packages not included in the binary mxe-octave installer. So in a sense it is not a very robust solution, but maybe good enough for Octave Windows binaries.

IMO it is reassuring that cross-built modules do work fine.
Yet I think in the long run it is better to find out why 64-bit modules compiled on Windows don't fit the cross-built Octave and fix it.
Maybe it is a matter of wrong header files, of libraries in the wrong order. I have compared octave_config_info output from just before the moment that the OF Windows package didn't work anymore and from yesterday; I found a few differences in FLIBS but I know too little about C++ to be able to do something with it.

As to final installation of cross-built packages:
It shouldn't be very hard to copy them into the right place in the share/octave/packages/<package_name> subdir (m-files, doc/, other subdirs), and lib/octave/packages/<packagename>/[canonical_host_type - api_version]/ subdirs (.oct files), resp.


Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 May 2015 01:41:13 PM UTC, comment #1: 

I thought (maybe wrongly?) that the cross built oct files will get installed anyway, not native built ones (I had removed configure and Makefile from the packages src directory, so we wouldnt be recompiled on windows in a c/s a few days ago [1])

[1]  http://hg.octave.org/mxe-octave/rev/160c1a23560c

John Donoghue <lostbard>
Group Member
Sat 02 May 2015 12:30:20 PM UTC, original submission:  

(Also see short discussion on maintainers ML here:
http://octave.1599824.n4.nabble.com/64-bit-Windows-OF-packages-build-failures-WAS-Cross-compile-io-package-tt4670201.html)

When building Octave-Forge packages for 64-bit Octave on the Windows side, the resulting .oct files can be "miscompiled" to the extent that they build fine but make Octave crash when running them.
Examples are csv2cell.cc/cell2csv.cc/csvexplode.cc/csvconcat.cc in the io package (see bug #44662) and _COM_.cc in the Windows package (see bug #44180).

It turns out that those 64-bit .oct files cross-built with mxe-octave (using the --enable-binary-packages and --enable-windows-64 configure options) run fine, once copied into place manually on the Windows side.

I think it must be a case of miscompilation as those OF modules work fine on (64-bit) Linux and 32-bit Octave (except, of course, _COM_.oct as that's a dedicated Windows module).

As JohnD mentions in the thread, Octave is cross-built using a multilib 32/64 bit build system, on Windows the .oct files are built using a 64-bit only build system.

In a sense this is a regression as .oct files could be built & run fine with 64-bit Octave on 64-bit Windows until some months ago.

As a temporary fix I've attached a changeset for the build_packages.m script to copy those .oct files over, + the build script itself.

I'll close the bugs #44180 & #44662 with a reference to this report.

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34363:  gcc-w64-fix.patch added by lostbard (1KiB - application/octet-stream)
file #33928:  build-gcc.zip added by philipnienhuis (22KiB - application/zip-compressed)
file #33921:  islfix.patch added by lostbard (1KiB - application/octet-stream)
file #33894:  gccupdates2.patch added by lostbard (7KiB - application/octet-stream)
file #33879:  build_packages.m added by philipnienhuis (3KiB - text/x-objective-c)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-09 lostbard Open/ClosedOpen Closed
    2015-07-09 lostbard StatusReady For Test Fixed
    2015-07-02 lostbard Attached File- Added gcc-w64-fix.patch, #34363
    2015-05-05 philipnienhuis Attached File- Added build-gcc.zip, #33928
    2015-05-05 lostbard Attached File- Added islfix.patch, #33921
    2015-05-04 lostbard StatusNone Ready For Test
        Assigned toNone lostbard
    2015-05-04 lostbard Attached File- Added gccupdates2.patch, #33894
    2015-05-02 philipnienhuis Attached File- Added build_packages.m, #33879
        Attached File- Added build_packages_64b.cs, #33880

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code