thread model for mxe-octave build

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

thread model for mxe-octave build

John W. Eaton
Administrator
I had someone ask why C++11 threads (mutext, condition_variable_any)
wasn't working with .oct files built with Octave 4.2.1.  After a little
searching, I found that we are configuring GCC with
--enable-threads=win32 instead of --enable-threads=posix.  Apparently
the latter is required to enable C++11 thread features.  Is there any
reason to not use --enable-threads=posix by default in our builds?  I
tried building native-gcc with this option and it allowed my test
program to compile but I don't know whether there might be other
problems.  From what I hve read, it seems that even if GCC is built with
this option you can still use Windows threading features directly.  I've
seen some mention of performance issues "in some situations" but no
explanation of what that might be.

jwe


-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

Daniel Sebald
On 02/22/2018 10:43 AM, John W. Eaton wrote:

> I had someone ask why C++11 threads (mutext, condition_variable_any)
> wasn't working with .oct files built with Octave 4.2.1.  After a little
> searching, I found that we are configuring GCC with
> --enable-threads=win32 instead of --enable-threads=posix.  Apparently
> the latter is required to enable C++11 thread features.  Is there any
> reason to not use --enable-threads=posix by default in our builds?  I
> tried building native-gcc with this option and it allowed my test
> program to compile but I don't know whether there might be other
> problems.  From what I hve read, it seems that even if GCC is built with
> this option you can still use Windows threading features directly.  I've
> seen some mention of performance issues "in some situations" but no
> explanation of what that might be.

What platforms are you referring to?  Windows build?  Linux build?  All?
  On Linux I'm seeing --enable-threads=posix after configuration.  After
bootstrap, the ./configure script indicates

gl_fnmatch_required=POSIX
gl_getopt_required=POSIX

Maybe that has an influence.

Dan


-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3
In reply to this post by John W. Eaton


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Thursday, February 22, 2018 11:44 AM
> To: John Donoghue; Octave Maintainers List
> Cc: [hidden email]
> Subject: thread model for mxe-octave build
>
> I had someone ask why C++11 threads (mutext, condition_variable_any) wasn't
> working with .oct files built with Octave 4.2.1.  After a little searching, I found
> that we are configuring GCC with
> --enable-threads=win32 instead of --enable-threads=posix.  Apparently the
> latter is required to enable C++11 thread features.  Is there any reason to not
> use --enable-threads=posix by default in our builds?  I tried building native-gcc
> with this option and it allowed my test program to compile but I don't know
> whether there might be other problems.  From what I hve read, it seems that
> even if GCC is built with this option you can still use Windows threading
> features directly.  I've seen some mention of performance issues "in some
> situations" but no explanation of what that might be.
>
> jwe

No reason I know of except that mxe was/is using win32



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 02/22/2018 11:57 AM, Daniel J Sebald wrote:

> What platforms are you referring to?  Windows build?  Linux build?  All?

The mxe-octave Windows build.  I don't think win32 threading makes sense
on any system other than Windows.

>   On Linux I'm seeing --enable-threads=posix after configuration.  After
> bootstrap, the ./configure script indicates

> gl_fnmatch_required=POSIX
> gl_getopt_required=POSIX
>
> Maybe that has an influence.

I don't think so.

jwe




-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
In reply to this post by John Donoghue-3
On 02/22/2018 12:02 PM, JohnD wrote:

>
>
>> -----Original Message-----
>> From: John W. Eaton [mailto:[hidden email]]
>> Sent: Thursday, February 22, 2018 11:44 AM
>> To: John Donoghue; Octave Maintainers List
>> Cc: [hidden email]
>> Subject: thread model for mxe-octave build
>>
>> I had someone ask why C++11 threads (mutext, condition_variable_any) wasn't
>> working with .oct files built with Octave 4.2.1.  After a little searching, I found
>> that we are configuring GCC with
>> --enable-threads=win32 instead of --enable-threads=posix.  Apparently the
>> latter is required to enable C++11 thread features.  Is there any reason to not
>> use --enable-threads=posix by default in our builds?  I tried building native-gcc
>> with this option and it allowed my test program to compile but I don't know
>> whether there might be other problems.  From what I hve read, it seems that
>> even if GCC is built with this option you can still use Windows threading
>> features directly.  I've seen some mention of performance issues "in some
>> situations" but no explanation of what that might be.
>>
>> jwe
>
> No reason I know of except that mxe was/is using win32

I tried changing the following change:

diff --git a/src/build-gcc.mk b/src/build-gcc.mk
--- a/src/build-gcc.mk
+++ b/src/build-gcc.mk
@@ -31,7 +31,7 @@ ifeq ($(MXE_SYSTEM),mingw)
      --disable-nls \
      --without-x \
      --disable-win32-registry \
-    --enable-threads=win32
+    --enable-threads=posix
    ifneq ($(TARGET),x86_64-w64-mingw32)
      $(PKG)_SYSDEP_CONFIGURE_OPTIONS += \
      --libdir='$(BUILD_TOOLS_PREFIX)/lib' \
diff --git a/src/native-gcc.mk b/src/native-gcc.mk
--- a/src/native-gcc.mk
+++ b/src/native-gcc.mk
@@ -25,7 +25,7 @@ ifeq ($(MXE_SYSTEM),mingw)
      --without-x \
      --disable-win32-registry \
      --with-native-system-header-dir='$(HOST_PREFIX)/include' \
-    --enable-threads=win32
+    --enable-threads=posix
    ifneq ($(ENABLE_WINDOWS_64),yes)
      $(PKG)_SYSDEP_CONFIGURE_OPTIONS += \
        $(ENABLE_SHARED_OR_STATIC) \

The build-gcc target fails because pthread.h is not available:

In file included from
/home/jwe/build/mxe-octave-w64-32-posix/tmp-build-gcc/gcc-7.2.0/libgcc/gthr.h:148:0,
                  from
/home/jwe/build/mxe-octave-w64-32-posix/tmp-build-gcc/gcc-7.2.0/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
  #include <pthread.h>
           ^~~~~~~~~~~
compilation terminated.
Makefile:915: recipe for target '_gcov_dump.o' failed
make[6]: *** [_gcov_dump.o] Error 1

Maybe this is just a dependency ordering issue, but I'm not sure how to
fix it.

Using --enable-threads=win32 for build-gcc and --enable-threads=posix
for native-gcc allows the build to succeed, but I'm not sure that is a
proper configuration.  Even if it is, we will also need to use posix
threads for build-gcc if we want to start using C++11 threading features
in Octave itself.  Any ideas about how to build a GCC cross compiler for
Windows that has the posix thread model enabled?

jwe


-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Friday, February 23, 2018 9:08 AM
> To: JohnD; 'Octave Maintainers List'
> Subject: Re: thread model for mxe-octave build
>
> On 02/22/2018 12:02 PM, JohnD wrote:
> >
> >
> >> -----Original Message-----
> >> From: John W. Eaton [mailto:[hidden email]]
> >> Sent: Thursday, February 22, 2018 11:44 AM
> >> To: John Donoghue; Octave Maintainers List
> >> Cc: [hidden email]
> >> Subject: thread model for mxe-octave build
> >>
> >> I had someone ask why C++11 threads (mutext, condition_variable_any)
> >> wasn't working with .oct files built with Octave 4.2.1.  After a
> >> little searching, I found that we are configuring GCC with
> >> --enable-threads=win32 instead of --enable-threads=posix.  Apparently
> >> the latter is required to enable C++11 thread features.  Is there any
> >> reason to not use --enable-threads=posix by default in our builds?  I
> >> tried building native-gcc with this option and it allowed my test
> >> program to compile but I don't know whether there might be other
> >> problems.  From what I hve read, it seems that even if GCC is built
> >> with this option you can still use Windows threading features
> >> directly.  I've seen some mention of performance issues "in some situations"
> but no explanation of what that might be.
> >>
> >> jwe
> >
> > No reason I know of except that mxe was/is using win32
>
> I tried changing the following change:
>
> diff --git a/src/build-gcc.mk b/src/build-gcc.mk
> --- a/src/build-gcc.mk
> +++ b/src/build-gcc.mk
> @@ -31,7 +31,7 @@ ifeq ($(MXE_SYSTEM),mingw)
>       --disable-nls \
>       --without-x \
>       --disable-win32-registry \
> -    --enable-threads=win32
> +    --enable-threads=posix
>     ifneq ($(TARGET),x86_64-w64-mingw32)
>       $(PKG)_SYSDEP_CONFIGURE_OPTIONS += \
>       --libdir='$(BUILD_TOOLS_PREFIX)/lib' \ diff --git a/src/native-gcc.mk
> b/src/native-gcc.mk
> --- a/src/native-gcc.mk
> +++ b/src/native-gcc.mk
> @@ -25,7 +25,7 @@ ifeq ($(MXE_SYSTEM),mingw)
>       --without-x \
>       --disable-win32-registry \
>       --with-native-system-header-dir='$(HOST_PREFIX)/include' \
> -    --enable-threads=win32
> +    --enable-threads=posix
>     ifneq ($(ENABLE_WINDOWS_64),yes)
>       $(PKG)_SYSDEP_CONFIGURE_OPTIONS += \
>         $(ENABLE_SHARED_OR_STATIC) \
>
> The build-gcc target fails because pthread.h is not available:
>
> In file included from
> /home/jwe/build/mxe-octave-w64-32-posix/tmp-build-gcc/gcc-
> 7.2.0/libgcc/gthr.h:148:0,
>                   from
> /home/jwe/build/mxe-octave-w64-32-posix/tmp-build-gcc/gcc-
> 7.2.0/libgcc/libgcov-interface.c:27:
> ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
>   #include <pthread.h>
>            ^~~~~~~~~~~
> compilation terminated.
> Makefile:915: recipe for target '_gcov_dump.o' failed
> make[6]: *** [_gcov_dump.o] Error 1
>
> Maybe this is just a dependency ordering issue, but I'm not sure how to fix it.
>
> Using --enable-threads=win32 for build-gcc and --enable-threads=posix for
> native-gcc allows the build to succeed, but I'm not sure that is a proper
> configuration.  Even if it is, we will also need to use posix threads for build-gcc
> if we want to start using C++11 threading features in Octave itself.  Any ideas
> about how to build a GCC cross compiler for Windows that has the posix thread
> model enabled?
>
> jwe

Not sure what part of the gcc install that is, but the mxe version of gcc.mk compiles posix threads as part of gcc.mk, before building the 'rest of gcc'

And then all their pthreads.mk does is install a package config file for it
 



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
On 02/23/2018 09:57 AM, JohnD wrote:

> Not sure what part of the gcc install that is, but the mxe version of gcc.mk compiles posix threads as part of gcc.mk, before building the 'rest of gcc'
>
> And then all their pthreads.mk does is install a package config file for it

Ah, OK, thanks.  I'll take a look at that and see if I can adapt it to
the build-gcc.mk file in mxe-octave.

jwe




-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
On 02/23/2018 10:08 AM, John W. Eaton wrote:

> On 02/23/2018 09:57 AM, JohnD wrote:
>
>> Not sure what part of the gcc install that is, but the mxe version of
>> gcc.mk compiles posix threads as part of gcc.mk, before building the
>> 'rest of gcc'
>>
>> And then all their pthreads.mk does is install a package config file
>> for it
>
> Ah, OK, thanks.  I'll take a look at that and see if I can adapt it to
> the build-gcc.mk file in mxe-octave.
I looked at the current MXE it allows building a cross compiler for
Windows with posix threads and the build seems to work.  So I tried to
adapt their rules to mxe-octave.  I pushed changeset to provide a macro
for unpacking and patching an archive, then I tried the attached diffs
for src/build-gcc.mk and building that is failing with a series for
messages like this when linking libgcc_s.a:

DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
DIR/usr/bin/x86_64-w64-mingw32-ld: cannot find -lpthread

I'm not sure whether this is due to multilib or that we are creating
links like

   usr/mingw -> DIR/usr/x86_64-w64-mingw32

when building.  It seems we have built up a lot of special cases of
creating directories (lib, lib3, lib64) and links that may no longer be
valid?

jwe


-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------

diffs.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John Donoghue-3
On 02/24/2018 10:52 AM, John W. Eaton wrote:

> On 02/23/2018 10:08 AM, John W. Eaton wrote:
>> On 02/23/2018 09:57 AM, JohnD wrote:
>>
>>> Not sure what part of the gcc install that is, but the mxe version
>>> of gcc.mk compiles posix threads as part of gcc.mk, before building
>>> the 'rest of gcc'
>>>
>>> And then all their pthreads.mk does is install a package config file
>>> for it
>>
>> Ah, OK, thanks.  I'll take a look at that and see if I can adapt it
>> to the build-gcc.mk file in mxe-octave.
>
> I looked at the current MXE it allows building a cross compiler for
> Windows with posix threads and the build seems to work.  So I tried to
> adapt their rules to mxe-octave.  I pushed changeset to provide a
> macro for unpacking and patching an archive, then I tried the attached
> diffs for src/build-gcc.mk and building that is failing with a series
> for messages like this when linking libgcc_s.a:
>
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> DIR/usr/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
>
> I'm not sure whether this is due to multilib or that we are creating
> links like
>
>   usr/mingw -> DIR/usr/x86_64-w64-mingw32
>
> when building.  It seems we have built up a lot of special cases of
> creating directories (lib, lib3, lib64) and links that may no longer
> be valid?
>
> jwe

My bet will be on multilib issues being the cause, I remember it was a
pain initially get it to work.


As an aside, I think you only reason we needed multilib was so that we
could also compile nsis in when doing win64.

Not sure if that is still a limitation with newer versions.


If I get a chance I will take a look at gcc and nsis as well.



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3


> -----Original Message-----
> From: John Donoghue [mailto:[hidden email]]
> Sent: Saturday, February 24, 2018 11:33 AM
> To: John W. Eaton; 'Octave Maintainers List'
> Subject: Re: thread model for mxe-octave build
>
> On 02/24/2018 10:52 AM, John W. Eaton wrote:
> > On 02/23/2018 10:08 AM, John W. Eaton wrote:
> >> On 02/23/2018 09:57 AM, JohnD wrote:
> >>
> >>> Not sure what part of the gcc install that is, but the mxe version
> >>> of gcc.mk compiles posix threads as part of gcc.mk, before building
> >>> the 'rest of gcc'
> >>>
> >>> And then all their pthreads.mk does is install a package config file
> >>> for it
> >>
> >> Ah, OK, thanks.  I'll take a look at that and see if I can adapt it
> >> to the build-gcc.mk file in mxe-octave.
> >
> > I looked at the current MXE it allows building a cross compiler for
> > Windows with posix threads and the build seems to work.  So I tried to
> > adapt their rules to mxe-octave.  I pushed changeset to provide a
> > macro for unpacking and patching an archive, then I tried the attached
> > diffs for src/build-gcc.mk and building that is failing with a series
> > for messages like this when linking libgcc_s.a:
> >
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> > -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> > -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> > -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/x86_64-w64-mingw32/lib/libpthread.dll.a when searching for
> > -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible
> > DIR/usr/mingw/lib/libpthread.dll.a when searching for -lpthread
> > DIR/usr/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
> >
> > I'm not sure whether this is due to multilib or that we are creating
> > links like
> >
> >   usr/mingw -> DIR/usr/x86_64-w64-mingw32
> >
> > when building.  It seems we have built up a lot of special cases of
> > creating directories (lib, lib3, lib64) and links that may no longer
> > be valid?
> >
> > jwe
>
> My bet will be on multilib issues being the cause, I remember it was a pain
> initially get it to work.
>
>
> As an aside, I think you only reason we needed multilib was so that we
> could also compile nsis in when doing win64.
>
> Not sure if that is still a limitation with newer versions.
>
>
> If I get a chance I will take a look at gcc and nsis as well.

I played around with it a little and see the same you are seeing with the incompatible thread line search.
Removing the links and similar efforts either lead to gcc not finding other files, or still incompatible threads.

Removing multilib however does compile gcc ok.



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
On 02/25/2018 04:24 PM, JohnD wrote:

>>
>> As an aside, I think you only reason we needed multilib was so that we
>> could also compile nsis in when doing win64.
>>
>> Not sure if that is still a limitation with newer versions.
>>
>>
>> If I get a chance I will take a look at gcc and nsis as well.
>
> I played around with it a little and see the same you are seeing with the incompatible thread line search.
> Removing the links and similar efforts either lead to gcc not finding other files, or still incompatible threads.
>
> Removing multilib however does compile gcc ok.

OK, and yes, I think it was only so we could build NSIS with a 32-bit
compiler.  MXE doesn't do multilib, but builds separate compilers for
32- or 64-bit builds.

jwe


-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
On 02/26/2018 08:41 AM, John W. Eaton wrote:

> On 02/25/2018 04:24 PM, JohnD wrote:
>>>
>>> As an aside, I think you only reason we needed multilib was so that we
>>> could also compile nsis in when doing win64.
>>>
>>> Not sure if that is still a limitation with newer versions.
>>>
>>>
>>> If I get a chance I will take a look at gcc and nsis as well.
>>
>> I played around with it a little and see the same you are seeing with
>> the incompatible thread line search.
>> Removing the links and similar efforts either lead to gcc not finding
>> other files, or still incompatible threads.
>>
>> Removing multilib however does compile gcc ok.
>
> OK, and yes, I think it was only so we could build NSIS with a 32-bit
> compiler.  MXE doesn't do multilib, but builds separate compilers for
> 32- or 64-bit builds.

I checked in two changes, one to for gcc and one for nsis.  Now gcc
builds with --enable-threads=posix and --disable-multilib.  That seems
to work.  The other change updates to nsis 3.03.  It builds with the
64-bit compiler but when running makensis, it fails to find plugins,
exiting with the message:

Plugin not found, cannot call InstallOptions::initDialog
Error in macro INSTALLOPTIONS_INITDIALOG on macroline 2
Error in macro MUI_FUNCTION_WELCOMEPAGE on macroline 48
Error in macro MUI_PAGE_WELCOME on macroline 23
Error in script "/scratch/jwe/build/mxe-octave-w64-32/dist/octave.nsi"
on line 68 -- aborting creation process
/scratch/jwe/build/mxe-octave-w64-32/binary-dist-rules.mk:191: recipe
for target 'octave-2018-02-26-18-13-installer.exe' failed



jwe



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Monday, February 26, 2018 6:17 PM
> To: JohnD
> Cc: 'Octave Maintainers List'
> Subject: Re: thread model for mxe-octave build
>
> On 02/26/2018 08:41 AM, John W. Eaton wrote:
> > On 02/25/2018 04:24 PM, JohnD wrote:
> >>>
> >>> As an aside, I think you only reason we needed multilib was so that
> >>> we could also compile nsis in when doing win64.
> >>>
> >>> Not sure if that is still a limitation with newer versions.
> >>>
> >>>
> >>> If I get a chance I will take a look at gcc and nsis as well.
> >>
> >> I played around with it a little and see the same you are seeing with
> >> the incompatible thread line search.
> >> Removing the links and similar efforts either lead to gcc not finding
> >> other files, or still incompatible threads.
> >>
> >> Removing multilib however does compile gcc ok.
> >
> > OK, and yes, I think it was only so we could build NSIS with a 32-bit
> > compiler.  MXE doesn't do multilib, but builds separate compilers for
> > 32- or 64-bit builds.
>
> I checked in two changes, one to for gcc and one for nsis.  Now gcc builds with -
> -enable-threads=posix and --disable-multilib.  That seems to work.  The other
> change updates to nsis 3.03.  It builds with the 64-bit compiler but when
> running makensis, it fails to find plugins, exiting with the message:
>
> Plugin not found, cannot call InstallOptions::initDialog Error in macro
> INSTALLOPTIONS_INITDIALOG on macroline 2 Error in macro
> MUI_FUNCTION_WELCOMEPAGE on macroline 48 Error in macro
> MUI_PAGE_WELCOME on macroline 23 Error in script
> "/scratch/jwe/build/mxe-octave-w64-32/dist/octave.nsi"
> on line 68 -- aborting creation process
> /scratch/jwe/build/mxe-octave-w64-32/binary-dist-rules.mk:191: recipe for
> target 'octave-2018-02-26-18-13-installer.exe' failed
>
>
>
> jwe

Tool a while to work out but makeinst-script needs to change !include "MUI.nsh" to !include "MUI2.nsh"



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3
In reply to this post by John W. Eaton


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Monday, February 26, 2018 6:17 PM
> To: JohnD
> Cc: 'Octave Maintainers List'
> Subject: Re: thread model for mxe-octave build
>
> On 02/26/2018 08:41 AM, John W. Eaton wrote:
> > On 02/25/2018 04:24 PM, JohnD wrote:
> >>>
> >>> As an aside, I think you only reason we needed multilib was so that
> >>> we could also compile nsis in when doing win64.
> >>>
> >>> Not sure if that is still a limitation with newer versions.
> >>>
> >>>
> >>> If I get a chance I will take a look at gcc and nsis as well.
> >>
> >> I played around with it a little and see the same you are seeing with
> >> the incompatible thread line search.
> >> Removing the links and similar efforts either lead to gcc not finding
> >> other files, or still incompatible threads.
> >>
> >> Removing multilib however does compile gcc ok.
> >
> > OK, and yes, I think it was only so we could build NSIS with a 32-bit
> > compiler.  MXE doesn't do multilib, but builds separate compilers for
> > 32- or 64-bit builds.
>
> I checked in two changes, one to for gcc and one for nsis.  Now gcc builds with -
> -enable-threads=posix and --disable-multilib.  That seems to work.  The other
> change updates to nsis 3.03.  It builds with the 64-bit compiler but when
> running makensis, it fails to find plugins, exiting with the message:
>
> Plugin not found, cannot call InstallOptions::initDialog Error in macro
> INSTALLOPTIONS_INITDIALOG on macroline 2 Error in macro
> MUI_FUNCTION_WELCOMEPAGE on macroline 48 Error in macro
> MUI_PAGE_WELCOME on macroline 23 Error in script
> "/scratch/jwe/build/mxe-octave-w64-32/dist/octave.nsi"
> on line 68 -- aborting creation process
> /scratch/jwe/build/mxe-octave-w64-32/binary-dist-rules.mk:191: recipe for
> target 'octave-2018-02-26-18-13-installer.exe' failed
>
>
>
> jwe


After reading the newer nsis documentation, there are a few other issues to address in the generated nsi script other than just MUI2.nsh
I'll take a look



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: thread model for mxe-octave build

John Donoghue-3
In reply to this post by John W. Eaton


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Monday, February 26, 2018 6:17 PM
> To: JohnD
> Cc: 'Octave Maintainers List'
> Subject: Re: thread model for mxe-octave build
>
> On 02/26/2018 08:41 AM, John W. Eaton wrote:
> > On 02/25/2018 04:24 PM, JohnD wrote:
> >>>
> >>> As an aside, I think you only reason we needed multilib was so that
> >>> we could also compile nsis in when doing win64.
> >>>
> >>> Not sure if that is still a limitation with newer versions.
> >>>
> >>>
> >>> If I get a chance I will take a look at gcc and nsis as well.
> >>
> >> I played around with it a little and see the same you are seeing with
> >> the incompatible thread line search.
> >> Removing the links and similar efforts either lead to gcc not finding
> >> other files, or still incompatible threads.
> >>
> >> Removing multilib however does compile gcc ok.
> >
> > OK, and yes, I think it was only so we could build NSIS with a 32-bit
> > compiler.  MXE doesn't do multilib, but builds separate compilers for
> > 32- or 64-bit builds.
>
> I checked in two changes, one to for gcc and one for nsis.  Now gcc builds with -
> -enable-threads=posix and --disable-multilib.  That seems to work.  The other
> change updates to nsis 3.03.  It builds with the 64-bit compiler but when
> running makensis, it fails to find plugins, exiting with the message:
>
> Plugin not found, cannot call InstallOptions::initDialog Error in macro
> INSTALLOPTIONS_INITDIALOG on macroline 2 Error in macro
> MUI_FUNCTION_WELCOMEPAGE on macroline 48 Error in macro
> MUI_PAGE_WELCOME on macroline 23 Error in script
> "/scratch/jwe/build/mxe-octave-w64-32/dist/octave.nsi"
> on line 68 -- aborting creation process
> /scratch/jwe/build/mxe-octave-w64-32/binary-dist-rules.mk:191: recipe for
> target 'octave-2018-02-26-18-13-installer.exe' failed
>
>
>
> jwe

I pushed up a change for nsis - the issue is that we were creating a win64 executable and dlls, however it was looking for 32 bit dll signatures.

Mxe.cc has the same issue with their nsis.



-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: thread model for mxe-octave build

John W. Eaton
Administrator
On 02/28/2018 11:04 AM, JohnD wrote:

> I pushed up a change for nsis - the issue is that we were creating a win64 executable and dlls, however it was looking for 32 bit dll signatures.

Thanks for the fix.

jwe




-----------------------------------------
Join us March 12-15 at CERN near Geneva
Switzerland for OctConf 2018.  More info:
https://wiki.octave.org/OctConf_2018
-----------------------------------------