bugGNU Octave - Bugs: bug #43805, mxarray.in.h gets installed


bug #43805: mxarray.in.h gets installed

Submitter:  John Donoghue <lostbard>
Submitted:  Fri 12 Dec 2014 01:26:02 PM UTC
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  johnd Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Wed 31 Dec 2014 04:46:08 AM UTC, comment #9: 

I went ahead and committed the change since it works for me and we never should have been including mxarray.h in the tarball anyways.  I made the change on the gui-release branch (http://hg.savannah.gnu.org/hgweb/octave/rev/50aedabe6bfb) and merged the change through to the default branch.

Rik <rik5>
Project Administrator
Tue 30 Dec 2014 11:42:17 PM UTC, comment #8: 

Closing again and opening a new bug report (bug #43908) for issues with OF-package building with 64-bit indexing builds of Octave.

See this discussion on maintainers ML:

Sorry for the noise.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 30 Dec 2014 10:03:20 PM UTC, comment #7: 

@Philip: Try the attached changeset and see if it works for you.  In addition, you might want to make extremely certain that there is not a lingering copy of mxarray.h somewhere in your MXE build tree.

find BUILD_TREE_DIR -name 'mxarray.h'
find BUILD_TREE_DIR -name 'mxarray.h' | xargs rm

(file #32738)

Rik <rik5>
Project Administrator
Tue 30 Dec 2014 09:13:16 PM UTC, comment #6: 

I think the problem is that we are distributing both mxarray.in.h and also mxarray.h.  The second should never be distributed because it is only correct for a particular build machine.

I'm running tests right now to see if that is the issue, but it will still take a few hours to know for sure.

Rik <rik5>
Project Administrator
Tue 30 Dec 2014 06:28:53 AM UTC, comment #5: 

In the generated mxarray.h file that is causing problems, what value is substituted for OCTAVE_IDX_TYPE in the definitions of mwSize, mwIndex, and mwSignedIndex?

John W. Eaton <jwe>
Project Administrator
Tue 30 Dec 2014 04:05:49 AM UTC, comment #4: 

The build environment appears correct.  DIST refers to whether a file should be included in the tar.gz file that is created for distribution.  We should distribute mxarray.in.h because it is the master file.  On each system where you run configure and make it should build an appropriate mxarray.h file from mxarray.in.h and then install mxarray.h.

At least on ordinary non-cross builds this appears to be fine.  The compilation warning that you quoted suggests that perhaps liboctave is being compiled with one version of mxarray.h, but then trying to link against a version compiled with a second, different version of mxarray.h.

Rik <rik5>
Project Administrator
Tue 30 Dec 2014 12:37:50 AM UTC, comment #3: 

Furthermore, in libinterp/Makefile.in I see:

  corefcn/mxarray.h \
  corefcn/oct-errno.cc \

suggesting that mxarray.h shouldn't be in the dist archive, while a little lower:

EXTRA_DIST = Makefile.in DOCSTRINGS config-features.sh \
        find-defun-files.sh gendoc.pl genprops.awk mk-errno-list \
        mk-pkg-add mkbuiltins mkdefs mkops oct-conf.in.h version.in.h \
        $(BUILT_DISTFILES) parse-tree/module.mk \
        corefcn/mxarray.in.h corefcn/oct-errno.in.cc \

and there seem to be a few more .in.h files mentioned there that look like they're intentionally included in the dist as well.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 30 Dec 2014 12:13:55 AM UTC, comment #2: 

Reopening this bug.

As outlined here:

it seems to be the fix for this bug that makes --enable-64 (cross-)builds break with the error message in the URL above.

I have no idea why such an obvious one-line change can have these consequences. As stated in the above post, mercurial needed to adapt a ridiculously large number of files going from the previous changeset by Kai (admittedly for default) to this one (for gui-release).

grepping for mxarray.h in the source tree I see various references to both mxarray.h.in and mxarray.in.h ???

I've provisionally set Status back to "None"

Philip Nienhuis <philipnienhuis>
Project Member
Sat 13 Dec 2014 01:21:58 AM UTC, comment #1: 

This was probably caused by a typo.  I fixed it on the gui-release branch in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/1085a65e9b9b).  Closing report.

Rik <rik5>
Project Administrator
Fri 12 Dec 2014 01:26:02 PM UTC, original submission:  

mxarray.in.h as well as generated file mxarray.h get installed on running make install.

mxarrayin.h should not be installed.

Appears to also be the case in the gui-release/default branch.

John Donoghue <lostbard>
Project Member


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

Attach Files:

Attached Files
file #32738:  mxarray.cset added by rik5 (726B - 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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lostbard (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 project members can vote.





    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-12-30 philipnienhuis StatusNone Fixed
        Open/ClosedOpen Closed
    2014-12-30 rik5 Attached File- Added mxarray.cset, #32738
    2014-12-30 philipnienhuis StatusFixed None
        Open/ClosedClosed Open
    2014-12-13 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.9