octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MXE: "undefined reference to `mxArray::mxArray(mxClassID, long long,


From: Philip Nienhuis
Subject: Re: MXE: "undefined reference to `mxArray::mxArray(mxClassID, long long, long long, mxComplexity)"
Date: Wed, 31 Dec 2014 00:43:05 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30

John W. Eaton wrote:
On 12/30/2014 03:25 PM, Philip Nienhuis wrote:
John W. Eaton wrote:

That problem should be fixed if the mxarray.h file is generated as part
of the build process.

Isn't that happening in the current sources?
In libinterp/Makefile.in I see:

:
BUILT_NODISTFILES = \
   corefcn/mxarray.h \
   corefcn/oct-errno.cc \
:

and further down:

:
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 \
:

This is the case for stable as well as default (and gui-release).
As far as I can guess these settings are just meant for a source
distribution tarball, right?

Yes, it is generated, but it is also present in the source directory in
recent tarballs on hydra.  When building in a separate build tree from
the sources, the -I compiler options are such that the mxarray.h file
from the src directory will be used.  That's the wrong version since it
wasn't generated correctly for 64-bit Windows systems.

So, how to proceed for the 64-bit indexing builds, or to be more exact:
how to properly fix building of some OF packages with 64-bit indexing Octave builds? (64-bit-indexing-Octave itself doesn't seem to be affected, that works fine AFAICS.)

A provisional fix was the situation before the fix of bug #43805, i.e. just patching mxarray.in.h and leaving libinterp/corefcn/module.mk as it was. I've reopened that bug yesterday based on the info I had then. Now, with your explanation I'll close it again as that bug fix merely uncovered the actual bug, and open a new one (#43908) for the mxarray.h generation issue (or rather, OF package building).

Philip




reply via email to

[Prev in Thread] Current Thread [Next in Thread]