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

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Mon 06 Apr 2015 08:10:02 PM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: John Donoghue <lostbard>
Originator Name: Philip NienhuisOpen/Closed: Closed
Release: otherOperating System: Microsoft Windows

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 07 Apr 2015 11:14:36 PM UTC, comment #18:

Pushed http://hg.octave.org/mxe-octave/rev/65b9641f852c

John Donoghue <lostbard>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
Tue 07 Apr 2015 02:48:17 PM UTC, comment #14:

Contents starts with ELF, so is a linux binary.

John Donoghue <lostbard>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
Tue 07 Apr 2015 12:05:50 PM UTC, comment #11:

Adding maintainer of control package to the CC list

Carnë Draug <carandraug>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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?

Philip Nienhuis <philipnienhuis>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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).

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach File(s):
   
   
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
  • -unavailable- added by carandraug (Lukas Reichlin - maintainer of control package)
  • -unavailable- added by lostbard (Posted a comment)
  • -unavailable- added by philipnienhuis (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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 12 Apr 2015 07:22:41 PM UTClostbardStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 07 Apr 2015 11:14:36 PM UTClostbardStatusPatch Submitted=>Ready For Test
    Tue 07 Apr 2015 04:45:32 PM UTClostbardAttached File-=>Added binutils-fix.patch, #33581
      StatusNone=>Patch Submitted
      Assigned toNone=>lostbard
    Tue 07 Apr 2015 12:05:50 PM UTCcarandraugCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1