bugGNU Octave - Bugs: bug #44753, [OF] control-2.8.0 won't install...

 
 

bug #44753: [OF] control-2.8.0 won't install on Octave built for 64-b Windows

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Mon 06 Apr 2015 08:10:02 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
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

Tue 07 Apr 2015 11:14:36 PM UTC, comment #18: 
John Donoghue <lostbard>
Group Member
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

John Donoghue <lostbard>
Group Member
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.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 07 Apr 2015 04:45:32 PM UTC, comment #15: 

This patch to mxe-octave works for me

(file #33581)

John Donoghue <lostbard>
Group Member
Tue 07 Apr 2015 02:48:17 PM UTC, comment #14: 

Contents starts with ELF, so is a linux binary.

John Donoghue <lostbard>
Group Member
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).

Philip Nienhuis <philipnienhuis>
Group Member
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.

John Donoghue <lostbard>
Group Member
Tue 07 Apr 2015 12:05:50 PM UTC, comment #11: 

Adding maintainer of control package to the CC list

Carnë Draug <carandraug>
Group Member
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 :)

John Donoghue <lostbard>
Group Member
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.

John Donoghue <lostbard>
Group Member
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

John Donoghue <lostbard>
Group Member
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:

$ ar.
./ar.: ./ar.: cannot execute binary file
$ ar.exe
Usage: d:\Octave\Octave32-4.0.0-rc2\bin\ar.exe [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
       d:\Octave\Octave32-4.0.0-rc2\bin\ar.exe -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
:


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?

Philip Nienhuis <philipnienhuis>
Group Member
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

John Donoghue <lostbard>
Group Member
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

Philip Nienhuis <philipnienhuis>
Group Member
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.

John Donoghue <lostbard>
Group Member
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.

Philip Nienhuis <philipnienhuis>
Group Member
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 ?

John Donoghue <lostbard>
Group Member
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?

John Donoghue <lostbard>
Group Member
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)


:
ar -rc slicotlibrary.a ./sltmp/*.o
/usr/bin/ar: /usr/bin/ar: cannot execute binary file
make: *** [slicotlibrary.a] Error 126
make: Leaving directory `/tmp/oct-6fJhlA/control/src'

pkg: error running `make' for the control package.
error: called from 'configure_make' in file C:\Programs\Octave\Octave32-4.0.0-rc1\share\octave\4.0.0-rc1\m\pkg\private\configure_make.m near line 96, column 9
>>


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).

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 #33581:  binutils-fix.patch added by lostbard (956B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by carandraug (Lukas Reichlin - maintainer of control package)
  • -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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-12 lostbard StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2015-04-07 lostbard StatusPatch Submitted Ready For Test
    2015-04-07 lostbard Attached File- Added binutils-fix.patch, #33581
        StatusNone Patch Submitted
        Assigned toNone lostbard
    2015-04-07 carandraug Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code