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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD
Checking before I create a bug.

In Windows, does anyone else have any issues building forge packages with
recent dev repo versions of octave?

Octave builds fine, however when trying to install packages (after
installing it in Windows), I get a constant compile error of:

g++: error: unrecognized command line option '-R', from mkoctave.  

Looking at the output there is a -R<lib_path_to_octave_build_lib>, similar
to other -L options, that I don't recall seeing before.

mkoctfile -p OCTAVE_LINK_DEPS, outputs the same -R option as seen in the
mkoctave g++ command.


I'm not sure when it started being an issue - I am currently at
23742:1f0daaf81955: don't use singleton for ch_manager, rename to
url_handle_manager

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mike Miller-4
On Fri, Jul 07, 2017 at 15:52:20 -0400, JohnD wrote:

> Octave builds fine, however when trying to install packages (after
> installing it in Windows), I get a constant compile error of:
>
> g++: error: unrecognized command line option '-R', from mkoctave.  
>
> Looking at the output there is a -R<lib_path_to_octave_build_lib>, similar
> to other -L options, that I don't recall seeing before.
>
> mkoctfile -p OCTAVE_LINK_DEPS, outputs the same -R option as seen in the
> mkoctave g++ command.

Is it OCTAVE_LINK_DEPS, OCTAVE_LINK_OPTS, OCT_LINK_DEPS, or
OCT_LINK_OPTS? Might as well show us all four.

OCTAVE_LINK_{DEPS,OPTS} are intended for building Octave itself, or
embedding Octave in a standalone executable (mkoctfile --standalone).
OCT_LINK_{DEPS,OPTS} are intended for building oct files.

In case you weren't sure, -R is libtool's option for adding a rpath
directory to a shared library or executable (it gets translated into the
appropriate linker option, -Wl,-rpath on GNU/Linux). It's very useful
for building with libtool, but not so useful if it's exported outside of
a libtool-based build system like this problem.

Other than that, I would trace it backwards, look for it in the build
log of default-octave, try to find where the definition is coming from.

I do see a "-Wl,-rpath-link" option being passed in default-octave.mk, I
wonder if it's possibly being translated into "-R" somewhere. I'm not
sure where that would be happening though.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

PhilipNienhuis
In reply to this post by JohnD
JohnD wrote
Checking before I create a bug.

In Windows, does anyone else have any issues building forge packages with
recent dev repo versions of octave?

Octave builds fine, however when trying to install packages (after
installing it in Windows), I get a constant compile error of:

g++: error: unrecognized command line option '-R', from mkoctave.  
Confirmed, I saw the same since some time.

Figuring it would be related to JWE's extensive surgery in Octave's internals lately I thougt to better let it rest for a while until the dust would have settled down.

Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD
In reply to this post by JohnD
>
> Message: 4
> Date: Fri, 7 Jul 2017 13:33:52 -0700
> From: Mike Miller <[hidden email]>
> To: [hidden email]
> Subject: Re: (mxe-octave) forge package build issues with compiler and
> dev octave
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Jul 07, 2017 at 15:52:20 -0400, JohnD wrote:
> > Octave builds fine, however when trying to install packages (after
> > installing it in Windows), I get a constant compile error of:
> >
> > g++: error: unrecognized command line option '-R', from mkoctave.
> >
> > Looking at the output there is a -R<lib_path_to_octave_build_lib>,
similar

> > to other -L options, that I don't recall seeing before.
> >
> > mkoctfile -p OCTAVE_LINK_DEPS, outputs the same -R option as seen in the
> > mkoctave g++ command.
>
> Is it OCTAVE_LINK_DEPS, OCTAVE_LINK_OPTS, OCT_LINK_DEPS, or
> OCT_LINK_OPTS? Might as well show us all four.
>
> OCTAVE_LINK_{DEPS,OPTS} are intended for building Octave itself, or
> embedding Octave in a standalone executable (mkoctfile --standalone).
> OCT_LINK_{DEPS,OPTS} are intended for building oct files.
>
> In case you weren't sure, -R is libtool's option for adding a rpath
> directory to a shared library or executable (it gets translated into the
> appropriate linker option, -Wl,-rpath on GNU/Linux). It's very useful
> for building with libtool, but not so useful if it's exported outside of
> a libtool-based build system like this problem.
>
> Other than that, I would trace it backwards, look for it in the build
> log of default-octave, try to find where the definition is coming from.
>
> I do see a "-Wl,-rpath-link" option being passed in default-octave.mk, I
> wonder if it's possibly being translated into "-R" somewhere. I'm not
> sure where that would be happening though.
>
> --
> mike

OCTAVE_LINK_DEPS has the -R
OCTAVE_LINK_OPTS does not
OCT_LINK_DEPS has the -R
OCT_LINK_OPTS does not

I'm trying a compile to take a look at default-octaves config.log to see
what it says




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD


> -----Original Message-----
> From: JohnD [mailto:[hidden email]]
> Sent: Saturday, July 08, 2017 8:15 PM
> To: [hidden email]
> Cc: 'Mike Miller'
> Subject: Re: (mxe-octave) forge package build issues with compiler and dev
> octave
>
> >
> > Message: 4
> > Date: Fri, 7 Jul 2017 13:33:52 -0700
> > From: Mike Miller <[hidden email]>
> > To: [hidden email]
> > Subject: Re: (mxe-octave) forge package build issues with compiler and
> > dev octave
> > Message-ID: <[hidden email]>
> > Content-Type: text/plain; charset=utf-8
> >
> > On Fri, Jul 07, 2017 at 15:52:20 -0400, JohnD wrote:
> > > Octave builds fine, however when trying to install packages (after
> > > installing it in Windows), I get a constant compile error of:
> > >
> > > g++: error: unrecognized command line option '-R', from mkoctave.
> > >
> > > Looking at the output there is a -R<lib_path_to_octave_build_lib>,
> similar
> > > to other -L options, that I don't recall seeing before.
> > >
> > > mkoctfile -p OCTAVE_LINK_DEPS, outputs the same -R option as seen in
> > > the mkoctave g++ command.
> >
> > Is it OCTAVE_LINK_DEPS, OCTAVE_LINK_OPTS, OCT_LINK_DEPS, or
> > OCT_LINK_OPTS? Might as well show us all four.
> >
> > OCTAVE_LINK_{DEPS,OPTS} are intended for building Octave itself, or
> > embedding Octave in a standalone executable (mkoctfile --standalone).
> > OCT_LINK_{DEPS,OPTS} are intended for building oct files.
> >
> > In case you weren't sure, -R is libtool's option for adding a rpath
> > directory to a shared library or executable (it gets translated into
> > the appropriate linker option, -Wl,-rpath on GNU/Linux). It's very
> > useful for building with libtool, but not so useful if it's exported
> > outside of a libtool-based build system like this problem.
> >
> > Other than that, I would trace it backwards, look for it in the build
> > log of default-octave, try to find where the definition is coming from.
> >
> > I do see a "-Wl,-rpath-link" option being passed in default-octave.mk,
> > I wonder if it's possibly being translated into "-R" somewhere. I'm
> > not sure where that would be happening though.
> >
> > --
> > mike
>
> OCTAVE_LINK_DEPS has the -R
> OCTAVE_LINK_OPTS does not
> OCT_LINK_DEPS has the -R
> OCT_LINK_OPTS does not
>
> I'm trying a compile to take a look at default-octaves config.log to see
what it
> says
>
>

From config.log

LTLIBICONV='-L/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib
-liconv -R/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib'

GNULIB_LINK_DEPS='  -lws2_32 -lws2_32  -ladvapi32  -lws2_32 -lws2_32
-L/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib -liconv
-R/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib  


Various other octave variables then also contain it, including
LIBOCTAVE_LINK_DEPS, LIBOCTGUI_LINK_DEP, LIBOCTINTERP_LINK_DEP



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John W. Eaton
Administrator
On 07/08/2017 09:13 PM, JohnD wrote:

> From config.log
>
> LTLIBICONV='-L/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib
> -liconv -R/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib'

This seems to be the problem.  It's coming from something in gnulib.  Do
we need to update again, or is this something that needs to be fixed in
gnulib?  And when did gcc/g++ stop supporting -R, anyway?

> GNULIB_LINK_DEPS='  -lws2_32 -lws2_32  -ladvapi32  -lws2_32 -lws2_32
> -L/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib -liconv
> -R/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib

This is just set in configure to be a bunch of variables that gnulib's
bootstrap script recommends using.

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mike Miller-4
On Sat, Jul 08, 2017 at 21:18:14 -0400, John W. Eaton wrote:

> On 07/08/2017 09:13 PM, JohnD wrote:
>
> > From config.log
> >
> > LTLIBICONV='-L/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib
> > -liconv -R/home/johnd/mxe-octave/build-dev/usr/i686-w64-mingw32/lib'
>
> This seems to be the problem.  It's coming from something in gnulib.  Do we
> need to update again, or is this something that needs to be fixed in gnulib?
> And when did gcc/g++ stop supporting -R, anyway?

I built stable-octave and default-octave and I see the same thing in
default-octave. Agree that this comes from the gnulib updates, pulling
in the iconv module as a dependency of something else.

I don't know whether gcc used to support -R or not, but to the best of
my knowledge it's an option that is normally interpreted by libtool and
turned into the appropriate linker option for the build system.

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.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John W. Eaton
Administrator
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.

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John W. Eaton
Administrator
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

Can someone who knows the Octave Forge build system better than I do
please take a look at these?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

PhilipNienhuis
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD
In reply to this post by JohnD
>
> Message: 3
> Date: Tue, 11 Jul 2017 22:35:16 -0700 (PDT)
> From: PhilipNienhuis <[hidden email]>
> To: [hidden email]
> Subject: Re: (mxe-octave) forge package build issues with compiler and
> dev octave
> Message-ID: <[hidden email]>
> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

PhilipNienhuis
JohnD wrote:

>>
>> Message: 3
>> Date: Tue, 11 Jul 2017 22:35:16 -0700 (PDT)
>> From: PhilipNienhuis <[hidden email]>
>> To: [hidden email]
>> Subject: Re: (mxe-octave) forge package build issues with compiler and
>> dev octave
>> Message-ID: <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD


> -----Original Message-----
> From: Philip Nienhuis [mailto:[hidden email]]
> Sent: Friday, July 14, 2017 2:54 PM
> To: JohnD; [hidden email]
> 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 <[hidden email]>
> >> To: [hidden email]
> >> Subject: Re: (mxe-octave) forge package build issues with compiler and
> >> dev octave
> >> Message-ID: <[hidden email]>
> >> 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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

PhilipNienhuis
JohnD wrote:
>
>> -----Original Message-----
>> From: Philip Nienhuis [mailto:[hidden email]]

>> JohnD wrote:

>>>> Date: Tue, 11 Jul 2017 22:35:16 -0700 (PDT)
>>>> From: PhilipNienhuis <[hidden email]>

>>>> John W. Eaton wrote
<snip>

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

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

<snip>

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

Good, I see you amended lapack to get built in a separate subdir.
Did you also include fixes for of-control? AFAIU (see above, but I can
be wrong) it has to be adapted to the newer lapack version.

Philip


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JohnD
> >>
> >> Today I've made an mxe-octave cross-build with the patched windows
>
> <snip>
>
> >> 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
>
> Good, I see you amended lapack to get built in a separate subdir.
> Did you also include fixes for of-control? AFAIU (see above, but I can be
wrong)
> it has to be adapted to the newer lapack version.
>
> Philip

I cheated I guess, and enabled depreciated functions in the mxe-octave
compile of lapack.
Without it, octave fails to compile as well due to bug #50463



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Philip Nienhuis
JohnD wrote
> >>
> >> Today I've made an mxe-octave cross-build with the patched windows
>
> <snip>
>
> >> 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
>
> Good, I see you amended lapack to get built in a separate subdir.
> Did you also include fixes for of-control? AFAIU (see above, but I can be
wrong)
> it has to be adapted to the newer lapack version.
>
> Philip

I cheated I guess, and enabled depreciated functions in the mxe-octave
compile of lapack.
Without it, octave fails to compile as well due to bug #50463
Well, that cheat may be a good solution after all, if it helps of-control to get built.

The patch in bug #50463 works fine and might be amended to mxe-octave as that contains a known lapack version. (But then of-control won't get built.)
For plain Octave that patch still needs a configure stanza to detect the locally installed lapack version. I suppose Carlo would fix that (see his comment 310 in bug #50463) but he didn't do that yet.

Philip
Loading...