bugGNU Octave - Bugs: bug #40222, OF windows pkg doesn't get...

 
 

bug #40222: OF windows pkg doesn't get installed anymore with Octave dev version

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Wed 09 Oct 2013 05:30:50 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Oct 2013 04:51:36 PM UTC, comment #9: 
Philip Nienhuis <philipnienhuis>
Group Member
Fri 18 Oct 2013 11:46:26 AM UTC, comment #8: 

Looks good to me, if that fixes the error you're seeing, and it looks to me like it should, go ahead and push it.

Mike Miller <mtmiller>
Group Member
Fri 18 Oct 2013 10:03:38 AM UTC, comment #7: 

OK here's a changeset w/o include guards.


(file #29398)

Philip Nienhuis <philipnienhuis>
Group Member
Sat 12 Oct 2013 07:55:11 PM UTC, comment #6: 

There's no need to check for an include guard, just include <string>. I think this is an appropriate fix, as long as you make that change.

Mike Miller <mtmiller>
Group Member
Sat 12 Oct 2013 07:46:20 PM UTC, comment #5: 

Attached is a changeset for version.in.h
 
Using this patch the OF windows package can be installed fine (tried on my two Windows boxes.)

An obvious question is whether this is the appropriate fix:

- Is it version.h's "fault" to blindly rely on <string.h>?

- Or should configure in the OF windows package be amended? (so far I've only encountered problems with the windows package, but I have only tried 10 or so OF packages.)

Note that with current MXE Windows build, without this fix the src/build_packages.m script will fail building the windows package.


(file #29363)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 09 Oct 2013 06:57:54 PM UTC, comment #4: 

Indeed, after inserting

#include <string>

at the top of OCTAVE_HOME>/include/octave-3.7.7+/octave/version.h, the windows package gets installed fine.

Could the cure be to do something like

#ifndef STRING_H
#include <string>
#endif

in version.in.h ?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 09 Oct 2013 05:58:09 PM UTC, comment #3: 

Yes, that's the one.

Michael Goffioul <goffioul>
Wed 09 Oct 2013 05:46:02 PM UTC, comment #2: 

Could it be related to changeset 17510:7542f4496974 ?

Some configure error messages apply to statements in version.in.h that have changed in the above mentioned changeset

Philip Nienhuis <philipnienhuis>
Group Member
Wed 09 Oct 2013 05:45:08 PM UTC, comment #1: 

The problem is that now <version.h> generated by octave is using std::string (it wasn't before), but it doesn't include <string>. So at the moment, if you want to include <version.h>, you need to include <string> before it.

I think <version.h> should include <string> itself.

Michael Goffioul <goffioul>
Wed 09 Oct 2013 05:30:50 PM UTC, original submission:  

See (parts of) the discussion about this in bug #40180.

While many other OF packages install w/o issues, (e.g., control, io, general, ...), the windows package can't get beyond the configure step. This issue popped up about a week ago.


> pkg install -verbose windows-1.2.1.tar.gz
mkdir (C:\Home\Philip\LOCALS~1\Temp\oct-61)
untar (windows-1.2.1.tar.gz, C:\Home\Philip\LOCALS~1\Temp\oct-61)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for mkoctfile... C:/octave/octave-2013-10-07-22-02/bin/mkoctfile-3.7.7+.exe
In file included from conftest.cc:2:0:
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:35:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:37:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:39:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:41:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:43:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:47:8: error: 'string' in namespace 'std' does not name a type
C:\octave\octave-2013-10-07-22-02\include\octave-3.7.7+\octave\../octave/version.h:51:8: error: 'string' in namespace 'std' does not name a type
g++: error: conftest.o: No such file or directory
configure: error: Could not run C:/octave/octave-2013-10-07-22-02/bin/mkoctfile-3.7.7+.exe

pkg: error running the configure script for windows.
error: called from 'configure_make' in file C:\octave\octave-2013-10-07-22-02\share\octave\3.7.7+\m\pkg\private\configure_make.m near line 72, column 9
error: called from:
error:   C:\octave\octave-2013-10-07-22-02\share\octave\3.7.7+\m\pkg\private\install.m at line 199, column 5
error:   C:\octave\octave-2013-10-07-22-02\share\octave\3.7.7+\m\pkg\pkg.m at line 394, column 9
>>


(Above lines may not be in strict chronological order as there are separate processes at work).

Manually trying the various commands in share/.../pkg/private/configure_make.m in an MSYS shell, I can only get as far as a complaint from configure a la "mkoctfile not found". But that doesn't match the error messages above => I gave up there.

Note that in lines 51-65 of configure_make.m, where the configure flags are cooked, 'mkoctfile ("-p", "AR")' always returns newlines at the end, e.g.:

>> mkoctfile("-p", "AR")
ar
>> int8 (mkoctfile("-p", "AR"))
ans =

   97  114   13   10


(note CRLF at end); these newlines end up in the final shell command a few lines down.
To my surprise this also happens on older (e.g., 3.7.5) Octave versions; apparently that wasn't a problem there ?!

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 #29398:  version.in.h.2.cs added by philipnienhuis (647B - text/x-csharp)
file #29363:  version.in.h.cs added by philipnienhuis (695B - 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 mtmiller (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-18 philipnienhuis StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2013-10-18 philipnienhuis Attached File- Added version.in.h.2.cs, #29398
    2013-10-12 mtmiller StatusNone Patch Submitted
    2013-10-12 philipnienhuis Attached File- Added version.in.h.cs, #29363

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code