Tue 07 Apr 2015 11:14:36 PM UTC, comment #18:
Pushed http://hg.octave.org/mxe-octave/rev/65b9641f852c
|
Tue 07 Apr 2015 08:08:41 PM UTC, comment #17:
I did a complete rebuild on my system, and everything else appeared to compile fine, so I will push the change to mxe later tonight
|
Tue 07 Apr 2015 07:18:06 PM UTC, comment #16:
OK thanks, I'll try tonight or tomorrow night.
In the mean time I've manually removed all ELF binaries (just sort on Type "file" and File Size > ~1 MB) and yep - it seems to work.
|
Tue 07 Apr 2015 04:45:32 PM UTC, comment #15:
This patch to mxe-octave works for me
(file #33581)
|
Tue 07 Apr 2015 02:48:17 PM UTC, comment #14:
Contents starts with ELF, so is a linux binary.
|
Tue 07 Apr 2015 02:30:55 PM UTC, comment #13:
@comment 8:
It is needed to add '.' at the end of 'ar', otherwise Windows/MSYS loader will silently add '.com', '.exe' or '.bat' to the file name :-) (that Windows loader is invoked behind the scenes after MSYS did its thing and hands the stuff to the Windows universe)
I slowly began to suspect it must be the extension-less executables that played havoc here, good that you finally pinpointed it down.
I wonder what those executables are anyway - nix executables? They are* binary files (most of them, that is; there are also some shell scripts).
|
Tue 07 Apr 2015 12:24:08 PM UTC, comment #12:
Its an issue cased by the mxe-octave build of build-binutils.
For mxe-octave, build_bintools, when not win64 mode, after installing ar, etc it moves ar, etc to $(TARGET)-as etc names.
It doesn't do the mv for win64, as the installer already names the binaries correctly - however, it (the makefile) still copies as 'ar' etc as well.
Im doing a change set and trying a rebuild where in win64 mode, it deletes the bare 'ar' etc in win64.
|
Tue 07 Apr 2015 12:05:50 PM UTC, comment #11:
Adding maintainer of control package to the CC list
|
Tue 07 Apr 2015 12:04:44 PM UTC, comment #10:
Comment 9 I guess is the same as what you were saying in comment 7 now that I reread it :)
|
Tue 07 Apr 2015 12:03:34 PM UTC, comment #9:
I think I see the issue - in the installed octave there is 2 ar binaries.
ar.exe (windows )
ar (Linux binary)
Not sure where that gets put in from, but if removed, using ar without extension works.
Just got to find where ar (no ext) gets copied from.
|
Tue 07 Apr 2015 11:59:49 AM UTC, comment #8:
Don't put the '.' at then end of ar in comment 7.
For some reason, something is resolving ar to /usr/bin when it should be /bin.
When providing ar.exe it does resolve to /bin and so works
|
Tue 07 Apr 2015 11:54:49 AM UTC, comment #7:
It is unclear to me what the ar. (w/o file extension) is used for. It is a binary file, but won't run in mingw/MSYS shell:
Moreover, I do not see binary files w/o extension in the 32-bit Octave bin/ subdir; I only see them in the 64-bit Octave bin/ folder. Could that explain a few things?
|
Tue 07 Apr 2015 10:43:20 AM UTC, comment #6:
mkoctfile and octave-config could be changed to return the name with EXEEXT extension perhaps
ALthough I dont know why ar works for 32 bit but not 64 bit without the extension
|
Tue 07 Apr 2015 09:40:25 AM UTC, comment #5:
Yes, just:
AR := ar.exe
will do the job. I suppose/hope that'll simplify things
|
Mon 06 Apr 2015 10:24:36 PM UTC, comment #4:
For 3. I mean if
AR := ar.exe
Does it work - ie: does it just need to specify exe extention, or does it actuall need the whole path?
For 2, I believe a few packages have issues in 64 bit cross compile last I tried it. I hadnt gotten around to looking at exact issue yet.
|
Mon 06 Apr 2015 09:21:59 PM UTC, comment #3:
1. I did: pkg install -forge -verbose control-2.8.0
2. No, I didn't specify --enable-binary-packages (in MXE)
If the now running build on Linux ends within 10 mins I'll try a cross-build tonight.
3. I don't follow. Do you mean this:
In Octave (on Windows), "mkoctfile -p AR" gives "ar", in 32-bit and in 64-bit Octave.
When I specified the full path to ar.exe in the Makefile for control pkg,
AR := C:/Programs/Octave/Octave32-4.0.0-rc1/bin/ar.exe
...control-2.8.0 installs fine ( $(AR) is recognized OK ).
I remember that when I made a typo in the path, the control pkg build ended with (IIRC) "rc not found" - rc is a parameter of ar.exe in the Makefile.
|
Mon 06 Apr 2015 08:31:57 PM UTC, comment #2:
Also, what happens if instead of returning 'ar' from mkoctfile, it returned ar.exe ?
|
Mon 06 Apr 2015 08:20:12 PM UTC, comment #1:
A couple of questions:
Is control-2,8.0 from octave forge, or in the mxe-octave installed src directory?
And when built, was --enable-binary-packages enabled?
|
Mon 06 Apr 2015 08:10:02 PM UTC, original submission:
With Octave dev version built with --enable-windows-64 (NOT 64-bit indexing, but below results are the same for 64-bit IDX)
If I enter the full Windows path (w. forward slashes) to <OCTAVE_HOME>/bin/ar.exe in the Makefile rather than the MKOCTFILE macro, control-2.8.0 installs OK.
I also saw this with the ltfat package, where both /usr/bin/ar and /usr/bin/ranlib are tried rather than ar.exe and ranlib.exe.
control-2.8.0 installs fine on 4.0.0-rc2 (32-bit).
Apparently mkoctfile gets confused on 64-bit Octave.
Makes me wonder whether mkoctfile gets built in a wrong way for Windows 64-bit systems (--enable-windows-64 in mxe), and if that might even be related to bug #44642 (speculation).
|