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)
|
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 ?
|
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.
|
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.
(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.:
(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 ?!
|