octave-maintainers
[Top][All Lists]
Advanced

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

RE: (mxe-octave) forge package build issues with compiler and dev octave


From: JohnD
Subject: RE: (mxe-octave) forge package build issues with compiler and dev octave
Date: Fri, 14 Jul 2017 15:22:25 -0400


> -----Original Message-----
> From: Philip Nienhuis [mailto:address@hidden
> Sent: Friday, July 14, 2017 2:54 PM
> To: JohnD; address@hidden
> Subject: Re: (mxe-octave) forge package build issues with compiler and dev
> octave
> 
> JohnD wrote:
> >>
> >> Message: 3
> >> Date: Tue, 11 Jul 2017 22:35:16 -0700 (PDT)
> >> From: PhilipNienhuis <address@hidden>
> >> To: address@hidden
> >> Subject: Re: (mxe-octave) forge package build issues with compiler and
> >>    dev     octave
> >> Message-ID: <address@hidden>
> >> Content-Type: text/plain; charset=us-ascii
> >>
> >> John W. Eaton wrote
> >>> On 07/10/2017 01:16 PM, John W. Eaton wrote:
> >>>> On 07/08/2017 09:56 PM, Mike Miller wrote:
> >>>>
> >>>>> I think it's fair for gnulib to put a libtool-specific option into
> >>>>> a variable called LTLIBICONV. The problem is when those options
> >>>>> get used by a non-libtool-aware build system, like calling gcc
> >>>>> directly. Gnulib also provides the corresponding LIBICONV for use
> >>>>> by non-libtool-based builds. This variable does not contain the -R
option.
> >>>>>
> >>>>> LTLIBICONV should be used for building Octave, but maybe LIBICONV
> >> should
> >>>>> be exported for use by mkoctfile and other build tools.
> >>>>
> >>>> Thanks.  I pushed a couple of changesets and now default-octave
> >>>> cross compiles.
> >>>>
> >>>> The next issue is that of-control is failing to build, apparently
> >>>> because of a change I made to octave-config.  Looking at that now.
> >>>
> >>> I checked in two more changes for mxe-octave to allow of-control and
> >>> of-general to build with current Octave sources:
> >>>
> >>>    http://hg.octave.org/mxe-octave/rev/eb8b37422e16
> >>>    http://hg.octave.org/mxe-octave/rev/60b45297db4a
> >>>
> >>> Now the following packages fail to build, all apparently due to the
> >>> same
> >>> obsolete(?) configure.base file that is not used in other Octave
> >>> Forge
> >>> packages:
> >>>
> >>>    of-linear-algebra
> >>>    of-netcdf
> >>>    of-windows
> >>
> >> Yes there were earlier issues with those packages caused by their old
> >> configure-make setup:
> >> http://savannah.gnu.org/bugs/?41131, sse comment #5
> >>
> >> After just deleting these 3 packages from the pertinent Makefile
> >> rule, of-database also fails to build with:
> >>
> >> :
> >> x86_64-w64-mingw32-g++ -std=gnu++11 -c
> >> -I/home/philip/devel/octdev/mxe/mxe_w64_qt4_201706010/usr/x86_64-
> w64-
> >> mingw32/include
> >> -I/home/philip/devel/octdev/mxe/mxe_w64_qt4_201706010/usr/x86_64-
> w64-
> >> mingw32/include/octave-4.3.0+/octave/..
> >> -I/home/philip/devel/octdev/mxe/mxe_w64_qt4_201706010/usr/x86_64-
> w64-
> >> mingw32/include/octave-4.3.0+/octave
> >> -I/home/philip/devel/octdev/mxe/mxe_w64_qt4_201706010/usr/x86_64-
> w64-
> >> mingw32/include
> >> -pthread -fopenmp -g -O2 -Wno-deprecated-declarations
> >> -I/home/philip/devel/octdev/mxe/mxe_w64_qt4_201706010/usr/include
> >> bytea2var.cc -o bytea2var.o
> >> bytea2var.cc: In function 'octave_value_list Fbytea2var(const
> >> octave_value_list&, int)':
> >> bytea2var.cc:97:22: error: 'flt_fmt_unknown' is not a member of
> >> 'oct_mach_info'
> >>        if (flt_fmt == oct_mach_info::flt_fmt_unknown)
> >>                       ^
> >> Makefile:95: recipe for target 'bytea2var.o' failed
> >> make[2]: *** [bytea2var.o] Error 1
> >>
> >>
> >> Dropping that one as well, the cross-build continues fine.
> >>
> >> So it is just those 4 of-packages that have issues being (cross-)built.
> >>
> >> Philip
> >>
> >>
> >>
> >
> > I pushed some changes to the windows repo for the windows package -
> > I'll push some changes for fixing the current windows package in mxe
> > today
> >
> > I have a fix for database, which I believe failed from these changes:
> > http://hg.savannah.gnu.org/hgweb/octave/rev/a732be902061, I will post
> > up as a new bug today
> >
> > Netcdf was posted on bug #51443, fixed and currently waiting release
> > as
> > 1.0.12
> 
> Today I've made an mxe-octave cross-build with the patched windows package
> and netcdf-1.012 (from the package release tracker).
> In addition I used a locally amended linear-algebra package version in
which
> the gsvd file stuff has been removed (as gsvd is in core Octave now). That
> linear-algebra package cross-builds fine in mxe-octave.
> 
> All these packages (except of-database) work fine on the Windows side.
> 
> Just a note:
> of-control didn't get cross-built, AFAICS because the development system I
used
> runs Mageia-6 that has Lapack-3.6.1 (see bug #50463). Obviously I needed
to
> upgrade lapack in mxe-octave as well (to have it accept the make dist
archive
> fed to mxe-octave).
> Then, when building of-control I got errors about missing functions that
were
> removed from Lapack 3.6+:
> 
> :
> slicotlibrary.a(AB08NX.o):AB08NX.f:(.text+0x848): undefined reference to
> `dlatzm_'
> slicotlibrary.a(AG08BY.o):AG08BY.f:(.text+0x878): undefined reference to
> `dlatzm_'
> slicotlibrary.a(SB01BY.o):SB01BY.f:(.text+0x313): undefined reference to
> `dlatzm_'
> slicotlibrary.a(SB01BY.o):SB01BY.f:(.text+0x48e): undefined reference to
> `dlatzm_'
> slicotlibrary.a(SB01BY.o):SB01BY.f:(.text+0x1266): undefined reference to
> `dlatzm_'
> slicotlibrary.a(SB01BY.o):SB01BY.f:(.text+0x1317): more undefined
references
> to `dlatzm_' follow
> slicotlibrary.a(SG03AD.o):SG03AD.f:(.text+0x7c8): undefined reference to
> `dgegs_'
> slicotlibrary.a(SG03BD.o):SG03BD.f:(.text+0x746): undefined reference to
> `dgegs_'
> slicotlibrary.a(SB01FY.o):SB01FY.f:(.text+0x465): undefined reference to
> `dlatzm_'
> 
> ..so  it looks like of-control may soon have to be updated to be
compatible with
> lapack 3.6+
> 
> BTW trying to build mxe-octave with lapack 3.7.0 I got an error that cmake
> doesn't want to build in the source directory but needs a separate build
dir. So I
> downgraded to lapack-3.6.1 that at least allowed default-octave to build
fine
> w/o changing anything else than the version number and SHA1 in
src/lapack.mk
> 
> Philip

A hour or so ago I pushed up fixes for the failing forge packages - I also
updated blas and lapack - all built of with me from a clean build directory




reply via email to

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