octave-maintainers
[Top][All Lists]
Advanced

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

RE: thread model for mxe-octave build


From: JohnD
Subject: RE: thread model for mxe-octave build
Date: Sun, 25 Feb 2018 16:24:43 -0500


> -----Original Message-----
> From: John Donoghue [mailto:address@hidden
> 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.




reply via email to

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