Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

PhilipNienhuis
<Maintainers ML added; FYI this thread started as a private conversation
over MXE fixes.
The next weeks I'll have very little time for Octave so I figured I'd
better hand it over to other possibly interested devs)

John Donoghue wrote:
> On 05/25/2013 03:56 PM, Philip Nienhuis wrote:
:
<snip>
:
>> FYI, a complete MXE build from clean checkout nowadays only takes 2.5
>> hours (on a Lenovo X230 w core i5 CPU, Mageia 2 32b)

(should read: starting from a dist archive: ~2 hours incl. moving zip to
native Windows & installing & testing)

>> BTW The last days I was trying to make a native (i.e. on Windows)
>> MinGW build env from the MXE stuff. I had some luck already in that
>> configure ran and part of the compile as well.
>> Motives:
>> - Not having to wait 30 minutes for a complete and blind Octave
>> cross-compile, + 10 mins for getting it to work on Windows itself, for
>> just a tiny patch
>> - I hope to be able to get Java in the picture; on MXE that doesn't
>> work as somehow the configure-generated files get confused if the
>> configure options in src/octave.mk are amended. Same goes for llvm
>
> I took a quick look at mxe on mingw, but didnt have much luck - but then
> really only spent 30 mins trying to get it to work - how many changes
> needed to get it to work under mingw ?

(Other motives:
- The MXE build tree supposedly contains almost everything needed for a
native MinGW build. MXE is a very effective way to build at least the
required dependencies.
- Preparing Octave for an MXE-build is time consuming: either make a
dist or manually swap files in a dist.tar.gz, recompute its SHA1, update
/src/octave.mk and copy the dist into /pkg )

The (my) aim is to get as far as ./run-octave, and to be able to build
and run with --debug-enabled. Once MinGW Octave is sufficiently stable,
I believe the archive (or installer) made with MXE on Linux is still the
superior option.

Two weeks ago I had a first try with octave 3.6.4 on an WinXP box, I got
as far as building in liboctave. Last week I started over again on
Windows 7 but didn't get as far yet as I ran out of time; below is a
rough sketch of what I did.
Hopefully other MinGW developers will pick up so we can also build
Octave "natively" on MinGW.

First an observation: the MinGW build tools do not seem to be thread
safe, or maybe it is Windows' NTFS filesystem that isn't (don't mention
FAT32). When building with "-j4" flag I got errors that some
intermediate file couldn't be accessed or written; that message
disappeared when I built on just one CPU core. But obviously that takes
3-4 times longer.


Install MinGW including MinGW dev tools but without compilers; stable
MinGW (using mingw-get) still gives gcc-4.6.2 while MXE contains 4.7.2.
MSYS is automatically included although most of MSYS is already in the
mxe-octave zip.

Move the complete mxe-octave build dir (i.e., one that has succesfully
built Octave) to a Windows partition (3.5 GB? IIRC). In ./mxe-octave the
subdir /cross-tools isn't needed, nor /pkg, /log, /dist, /src + maybe a
few others. MinGW and mxe-octave do not have to be merged, if only paths
are entered correctly in MinGW style (e.g., /c/mingw/bin for
C:\mingw\bin, /c/mxe-octave/usr/...)
Probably some clever mount-ing can help here but I didn't try yet.
NB: soft links do not exist on Windows, if you try "ln -s" you'll notice
files are actually copied.
Perhaps move mxe-octave such that from within an MSYS shell it mimics
the tree on Linux (see below). In that case watch the 254 char limit for
full path names on Windows.

Add all .../bin dirs in mxe-octave (except msys-base/bin) to the PATH (I
use .profile in mingw/msys/1.0/home/<username> for that), also add
subdir mxe-octave/usr/lib/gcc/i686-pc-mingw32 - but perhaps one can also
copy the one file there to some bin subdir to keep the PATH short.
I entered only the MinGW PATH + mxe-octave dirs + /c/windows +
/c/windows/system32 into an "export PATH='...'" statement to get rid of
all '/c/Program Files/<etc>' stuff except /c/Program Files/gs/gs9.07/bin
- had I known before I would have installed ghostscript elsewhere.

As a rule of thumb the prerequisites for MXE itself (i.e. on Linux)
translate to some extent for mxe-under-mingw.
At least autoconf and automake are included in mingw (-dev-tools).
pkg-config.exe is apparently needed, get it from somewhere (I used
Tatsuro's dependency libs for ripping it from there). Maybe
pkg-config.exe itself isn't needed after all, but I didn't get that far yet.

Set include dirs + other flags in environment vars (again I used
Tatsuro's work as a template). Also set PKG_CONFIG_PATH to ...? (hmmm
forgot what it was exactly but you'll get an error message mentioning
the proper location).
Remember "/" = msys-base (i.e., \Mingw\msys\1.0\)

Currently a stumbling block is that the MXE-built native compilers don't
work properly in 64-bit Windows 7 (which is on my main build machine
these days). This will become evident during ./configure, but also
during installation of packages in Octave (typically configure complains
that "g++ can't build executables").
The fix for octave itself (pkg install ...) is easy: just set octave.exe
"WinXP compatible" and binary package building goes OK.
For MinGW/MSYS I hope I'd only have to set some main msys executable to
WinXP-SP3 compatible first (I suppose all other .exes it calls will be
treated similarly), but I still have to find out which one that is. But
then again it may be more complicated, who knows.

 From then on I suppose (hope) it is just a matter of trying first the
easy case with stable Octave-3.6.4 and while trying to build that, solve
issues as they appear. In a next step try 3.7.5+

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
On 05/26/2013 03:32 PM, Philip Nienhuis wrote:

> The (my) aim is to get as far as ./run-octave, and to be able to build
> and run with --debug-enabled. Once MinGW Octave is sufficiently stable,
> I believe the archive (or installer) made with MXE on Linux is still the
> superior option.

I'm working on some changes that should make it possible to use the
mxe-octave build environment as a native or cross-compile system.

I've focused first on trying to make it work for my Debian system, but
my next step is to try a native build on a Windows system with a
minimal MinGW system installed.

I'm close to being able to do the following on a Debian system that
starts out with no development tools:

   * install the base system (no development tools)

   * install a minimal set of development tools using apt:

       bash, bzip2, gcc, g++, gfortran, make, patch, perl, sed, wget,
       unzip, ghostscript, unzip, libx11-dev, libxext-dev,
       libgl1-mesa-dev, glu, mercurial

   * clone mxe-octave archive

   * make octave JOBS=N

Obviously, this doesn't make much sense on a current Debian system,
but it might on a RHEL 5 system that doesn't have up to date tools.
Or, on a system that has some up to date tools, you could install most
depdencies using the system's package management tool, then install
the rest using mxe-octave.  However, I have no plans to try to
automate that task.  I'm not trying to take over the job of
packaging Octave on systems like Debian and Fedora that already have
good packages for Octave.  I just want to have a reasonable way to
automate the task of building Octave and all the dependencies on
systems that do not have good package systems.

I plan to check in my changes once I've verified that I can still use
mxe-octave to cross compile for a Windows system using the MinGW
compiler, probably within a day or two.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

PhilipNienhuis
John W. Eaton wrote
On 05/26/2013 03:32 PM, Philip Nienhuis wrote:

> The (my) aim is to get as far as ./run-octave, and to be able to build
> and run with --debug-enabled. Once MinGW Octave is sufficiently stable,
> I believe the archive (or installer) made with MXE on Linux is still the
> superior option.

I'm working on some changes that should make it possible to use the
mxe-octave build environment as a native or cross-compile system.

I've focused first on trying to make it work for my Debian system, but
my next step is to try a native build on a Windows system with a
minimal MinGW system installed.

I'm close to being able to do the following on a Debian system that
starts out with no development tools:

   * install the base system (no development tools)

   * install a minimal set of development tools using apt:

       bash, bzip2, gcc, g++, gfortran, make, patch, perl, sed, wget,
       unzip, ghostscript, unzip, libx11-dev, libxext-dev,
       libgl1-mesa-dev, glu, mercurial

   * clone mxe-octave archive

   * make octave JOBS=N
Could you also have a look at why mxe builds break when configure options in octave.mk are adapted, please?  That occurs not only when trying to build with Java but also with just llvm.
I think that it should at least be possible to also build with JIT, regardless of its current stability and state - after all it seems to build and work properly on Linux.
If you deem llvm not worthwile presently I'd wonder why llvm is built at all in mxe-octave (especially because llvm takes about 10-15 % of total build time).

Obviously, this doesn't make much sense on a current Debian system,
but it might on a RHEL 5 system that doesn't have up to date tools.
Or, on a system that has some up to date tools, you could install most
depdencies using the system's package management tool, then install
the rest using mxe-octave.  However, I have no plans to try to
automate that task.  I'm not trying to take over the job of
packaging Octave on systems like Debian and Fedora that already have
good packages for Octave.
Fair enough. Once again thank you for making mxe-octave; it has removed an enormous stumbling block for building on Windows systems.

I just want to have a reasonable way to
automate the task of building Octave and all the dependencies on
systems that do not have good package systems.
Just for clarity: I am not aiming to be able to completely build on MinGW/Windows (although once Octave builds there the next steps are pretty straightforward).
My MXE/MinGW attempts were primarily meant to make debugging easier and more time efficient.
I like the standardized dependencies and add-ons that mxe-octave makes possible.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
In reply to this post by John W. Eaton
On 05/27/2013 11:49 PM, John W. Eaton wrote:

> I plan to check in my changes once I've verified that I can still use
> mxe-octave to cross compile for a Windows system using the MinGW
> compiler, probably within a day or two.

I checked in the changes.  By default, the same mingw cross build is done.

If you want to attempt a native build, edit the settings at the top of
the top-level Makefile.

If you want to omit some dependencies, then edit the list of
dependencies in the src/octave.mk file (or any other .mk file that lists
a dependency that you don't want to build, but instead expect to find
already installed on your system).

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
In reply to this post by PhilipNienhuis
On 05/28/2013 03:36 PM, PhilipNienhuis wrote:

> Could you also have a look at why mxe builds break when configure options in
> octave.mk are adapted, please?

No, but I'll review/consider any patches.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3
In reply to this post by John W. Eaton
On 05/27/2013 11:49 PM, John W. Eaton wrote:
On 05/26/2013 03:32 PM, Philip Nienhuis wrote:

The (my) aim is to get as far as ./run-octave, and to be able to build
and run with --debug-enabled. Once MinGW Octave is sufficiently stable,
I believe the archive (or installer) made with MXE on Linux is still the
superior option.

I'm working on some changes that should make it possible to use the
mxe-octave build environment as a native or cross-compile system.

I've focused first on trying to make it work for my Debian system, but
my next step is to try a native build on a Windows system with a
minimal MinGW system installed.

I'm close to being able to do the following on a Debian system that
starts out with no development tools:

  * install the base system (no development tools)

  * install a minimal set of development tools using apt:

      bash, bzip2, gcc, g++, gfortran, make, patch, perl, sed, wget,
      unzip, ghostscript, unzip, libx11-dev, libxext-dev,
      libgl1-mesa-dev, glu, mercurial

  * clone mxe-octave archive

  * make octave JOBS=N

Obviously, this doesn't make much sense on a current Debian system,
but it might on a RHEL 5 system that doesn't have up to date tools.
Or, on a system that has some up to date tools, you could install most
depdencies using the system's package management tool, then install
the rest using mxe-octave.  However, I have no plans to try to
automate that task.  I'm not trying to take over the job of
packaging Octave on systems like Debian and Fedora that already have
good packages for Octave.  I just want to have a reasonable way to
automate the task of building Octave and all the dependencies on
systems that do not have good package systems.

I plan to check in my changes once I've verified that I can still use
mxe-octave to cross compile for a Windows system using the MinGW
compiler, probably within a day or two.

jwe
Just out of interest sake, I tried mxe-octave in both a native mingw environment and a redhat 6.3 (to build as a  redhat target) as clean builds.

I found as Philip mentioned that mingw doesnt like multitasking the make so I was stuck with --jobs 1

Also (as Philip had also mentioned), mingw in windows does not support links, doing a copy instead, which makes looking at the latest log file for a built (or failed) program annoying as the log/ file is empty, since it was linked at the start of the build.

Can we change the build output to go to the link file rather than the actual file so that it will still work in linux, but will also then have a copy of the latest log file in log/  (the 0 size  one in windows would then be in the date stamped folder)
I will push a change to do this if there are no objecttions?

Mingw failed trying to build build-flex since it couldnt regex.h, however I wasnt too concerned on that as flex is a package available in mingw already.

It also failed on build-pkg-config during the install part (it compiled ok, however was another ln issue): log said:

Pkg-config failed:

libtool: install: /bin/install -c .libs/pkg-config.exe /home/jdonoghue/mxe-octave/usr/bin/pkg-config.exe

make  install-exec-hook

make[5]: Entering directory `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-config-0.28.build'

cd /home/jdonoghue/mxe-octave/usr/bin && ln pkg-config.exe i686-pc-mingw32-pkg-config.exe

ln: creating hard link `i686-pc-mingw32-pkg-config.exe' to `pkg-config.exe': File exists

make[5]: *** [install-exec-hook] Error 1

make[5]: Leaving directory `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-

config-0.28.build' make[4]: *** [install-exec-am] Error 2


For Redhat, I actually got to the octave build with very few issues :)
fltk requires freetype to build - when adding to its deps (as a native), it built fltk ok.

Font-config failed as it didnt have docbook2pdf - which I guess we dont need to install for a build anyway - I disabled with the --disable-docs option in configure.

Qt failed as it couldnt find GL/gl.h - I disabled gl in configure to get it to work, however it should have been easy enough to get GL devel installed.

It then failed at building octave as it didnt like the fortran compiler .... guess I will have to tell it to build the tools and see what happens.

Anyway, it there are no objections I will also push the change for fltk and font-config.mk.

John D





Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
On 05/29/2013 06:41 PM, John Donoghue wrote:

> On 05/27/2013 11:49 PM, John W. Eaton wrote:
>> On 05/26/2013 03:32 PM, Philip Nienhuis wrote:
>>
>>> The (my) aim is to get as far as ./run-octave, and to be able to build
>>> and run with --debug-enabled. Once MinGW Octave is sufficiently stable,
>>> I believe the archive (or installer) made with MXE on Linux is still the
>>> superior option.
>>
>> I'm working on some changes that should make it possible to use the
>> mxe-octave build environment as a native or cross-compile system.
>>
>> I've focused first on trying to make it work for my Debian system, but
>> my next step is to try a native build on a Windows system with a
>> minimal MinGW system installed.
>>
>> I'm close to being able to do the following on a Debian system that
>> starts out with no development tools:
>>
>>   * install the base system (no development tools)
>>
>>   * install a minimal set of development tools using apt:
>>
>>       bash, bzip2, gcc, g++, gfortran, make, patch, perl, sed, wget,
>>       unzip, ghostscript, unzip, libx11-dev, libxext-dev,
>>       libgl1-mesa-dev, glu, mercurial
>>
>>   * clone mxe-octave archive
>>
>>   * make octave JOBS=N
>>
>> Obviously, this doesn't make much sense on a current Debian system,
>> but it might on a RHEL 5 system that doesn't have up to date tools.
>> Or, on a system that has some up to date tools, you could install most
>> depdencies using the system's package management tool, then install
>> the rest using mxe-octave.  However, I have no plans to try to
>> automate that task.  I'm not trying to take over the job of
>> packaging Octave on systems like Debian and Fedora that already have
>> good packages for Octave.  I just want to have a reasonable way to
>> automate the task of building Octave and all the dependencies on
>> systems that do not have good package systems.
>>
>> I plan to check in my changes once I've verified that I can still use
>> mxe-octave to cross compile for a Windows system using the MinGW
>> compiler, probably within a day or two.
>>
>> jwe
> Just out of interest sake, I tried mxe-octave in both a native mingw
> environment and a redhat 6.3 (to build as a  redhat target) as clean builds.
>
> I found as Philip mentioned that mingw doesnt like multitasking the make
> so I was stuck with --jobs 1
>
> Also (as Philip had also mentioned), mingw in windows does not support
> links, doing a copy instead, which makes looking at the latest log file
> for a built (or failed) program annoying as the log/ file is empty,
> since it was linked at the start of the build.
>
> Can we change the build output to go to the link file rather than the
> actual file so that it will still work in linux, but will also then have
> a copy of the latest log file in log/  (the 0 size  one in windows would
> then be in the date stamped folder)
> I will push a change to do this if there are no objecttions?

None from me.

> Mingw failed trying to build build-flex since it couldnt regex.h,
> however I wasnt too concerned on that as flex is a package available in
> mingw already.
>
> It also failed on build-pkg-config during the install part (it compiled
> ok, however was another ln issue): log said:
>
> Pkg-config failed:
>
> libtool: install: /bin/install -c .libs/pkg-config.exe
> /home/jdonoghue/mxe-octave/usr/bin/pkg-config.exe
>
> make  install-exec-hook
>
> make[5]: Entering directory
> `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-config-0.28.build'
>
> cd /home/jdonoghue/mxe-octave/usr/bin && ln pkg-config.exe
> i686-pc-mingw32-pkg-config.exe
>
> ln: creating hard link `i686-pc-mingw32-pkg-config.exe' to
> `pkg-config.exe': File exists
>
> make[5]: *** [install-exec-hook] Error 1
>
> make[5]: Leaving directory
> `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-
>
> config-0.28.build'make[4]: *** [install-exec-am] Error 2

OK, so we need to track down all the uses of ln and change them to
$(LN) or $(LN_S) and set those variables appropriately in the Makefile
depending on whether we are building natively on Windows.

> For Redhat, I actually got to the octave build with very few issues :)
> fltk requires freetype to build - when adding to its deps (as a native),
> it built fltk ok.
>
> Font-config failed as it didnt have docbook2pdf - which I guess we dont
> need to install for a build anyway - I disabled with the --disable-docs
> option in configure.
>
> Qt failed as it couldnt find GL/gl.h - I disabled gl in configure to get
> it to work, however it should have been easy enough to get GL devel
> installed.
>
> It then failed at building octave as it didnt like the fortran compiler
> .... guess I will have to tell it to build the tools and see what happens.
>
> Anyway, it there are no objections I will also push the change for fltk
> and font-config.mk.

OK.

I'm trying a build on CentOS 5.9 now.

But I'm not sure how necessary the MXE thing is for these systems if
you are willing to use the EPEL repository.  That seems to give most
dependencies.  I guess I'll find out soon whether the versions are
recent enough.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3
On 05/29/2013 06:51 PM, John W. Eaton wrote:

> On 05/29/2013 06:41 PM, John Donoghue wrote:
>> On 05/27/2013 11:49 PM, John W. Eaton wrote:
>>> On 05/26/2013 03:32 PM, Philip Nienhuis wrote:
>>>
>>>> The (my) aim is to get as far as ./run-octave, and to be able to build
>>>> and run with --debug-enabled. Once MinGW Octave is sufficiently
>>>> stable,
>>>> I believe the archive (or installer) made with MXE on Linux is
>>>> still the
>>>> superior option.
>>>
>>> I'm working on some changes that should make it possible to use the
>>> mxe-octave build environment as a native or cross-compile system.
>>>
>>> I've focused first on trying to make it work for my Debian system, but
>>> my next step is to try a native build on a Windows system with a
>>> minimal MinGW system installed.
>>>
>>> I'm close to being able to do the following on a Debian system that
>>> starts out with no development tools:
>>>
>>>   * install the base system (no development tools)
>>>
>>>   * install a minimal set of development tools using apt:
>>>
>>>       bash, bzip2, gcc, g++, gfortran, make, patch, perl, sed, wget,
>>>       unzip, ghostscript, unzip, libx11-dev, libxext-dev,
>>>       libgl1-mesa-dev, glu, mercurial
>>>
>>>   * clone mxe-octave archive
>>>
>>>   * make octave JOBS=N
>>>
>>> Obviously, this doesn't make much sense on a current Debian system,
>>> but it might on a RHEL 5 system that doesn't have up to date tools.
>>> Or, on a system that has some up to date tools, you could install most
>>> depdencies using the system's package management tool, then install
>>> the rest using mxe-octave.  However, I have no plans to try to
>>> automate that task.  I'm not trying to take over the job of
>>> packaging Octave on systems like Debian and Fedora that already have
>>> good packages for Octave.  I just want to have a reasonable way to
>>> automate the task of building Octave and all the dependencies on
>>> systems that do not have good package systems.
>>>
>>> I plan to check in my changes once I've verified that I can still use
>>> mxe-octave to cross compile for a Windows system using the MinGW
>>> compiler, probably within a day or two.
>>>
>>> jwe
>> Just out of interest sake, I tried mxe-octave in both a native mingw
>> environment and a redhat 6.3 (to build as a  redhat target) as clean
>> builds.
>>
>> I found as Philip mentioned that mingw doesnt like multitasking the make
>> so I was stuck with --jobs 1
>>
>> Also (as Philip had also mentioned), mingw in windows does not support
>> links, doing a copy instead, which makes looking at the latest log file
>> for a built (or failed) program annoying as the log/ file is empty,
>> since it was linked at the start of the build.
>>
>> Can we change the build output to go to the link file rather than the
>> actual file so that it will still work in linux, but will also then have
>> a copy of the latest log file in log/  (the 0 size  one in windows would
>> then be in the date stamped folder)
>> I will push a change to do this if there are no objecttions?
>
> None from me.
>
>> Mingw failed trying to build build-flex since it couldnt regex.h,
>> however I wasnt too concerned on that as flex is a package available in
>> mingw already.
>>
>> It also failed on build-pkg-config during the install part (it compiled
>> ok, however was another ln issue): log said:
>>
>> Pkg-config failed:
>>
>> libtool: install: /bin/install -c .libs/pkg-config.exe
>> /home/jdonoghue/mxe-octave/usr/bin/pkg-config.exe
>>
>> make  install-exec-hook
>>
>> make[5]: Entering directory
>> `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-config-0.28.build'
>>
>> cd /home/jdonoghue/mxe-octave/usr/bin && ln pkg-config.exe
>> i686-pc-mingw32-pkg-config.exe
>>
>> ln: creating hard link `i686-pc-mingw32-pkg-config.exe' to
>> `pkg-config.exe': File exists
>>
>> make[5]: *** [install-exec-hook] Error 1
>>
>> make[5]: Leaving directory
>> `/home/jdonoghue/mxe-octave/tmp-build-pkg-config/pkg-
>>
>> config-0.28.build'make[4]: *** [install-exec-am] Error 2
>
> OK, so we need to track down all the uses of ln and change them to
> $(LN) or $(LN_S) and set those variables appropriately in the Makefile
> depending on whether we are building natively on Windows.
>
>> For Redhat, I actually got to the octave build with very few issues :)
>> fltk requires freetype to build - when adding to its deps (as a native),
>> it built fltk ok.
>>
>> Font-config failed as it didnt have docbook2pdf - which I guess we dont
>> need to install for a build anyway - I disabled with the --disable-docs
>> option in configure.
>>
>> Qt failed as it couldnt find GL/gl.h - I disabled gl in configure to get
>> it to work, however it should have been easy enough to get GL devel
>> installed.
>>
>> It then failed at building octave as it didnt like the fortran compiler
>> .... guess I will have to tell it to build the tools and see what
>> happens.
>>
>> Anyway, it there are no objections I will also push the change for fltk
>> and font-config.mk.
>
> OK.
>
> I'm trying a build on CentOS 5.9 now.
>
> But I'm not sure how necessary the MXE thing is for these systems if
> you are willing to use the EPEL repository.  That seems to give most
> dependencies.  I guess I'll find out soon whether the versions are
> recent enough.
>
> jwe
Pushed changes:
http://hg.octave.org/mxe-octave/rev/733c487c69c6
http://hg.octave.org/mxe-octave/rev/7d692ab680ab

Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
In reply to this post by John W. Eaton
On 05/29/2013 06:51 PM, John W. Eaton wrote:

> OK, so we need to track down all the uses of ln and change them to
> $(LN) or $(LN_S) and set those variables appropriately in the Makefile
> depending on whether we are building natively on Windows.

I made this change.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3
I just tried a native build and it failed to compile binutils - the issue is the autodetect of target, which needs to change to:

TARGET := $(`tools/config.guess`)

 
On Thu, May 30, 2013 at 1:32 PM, John W. Eaton <[hidden email]> wrote:
On 05/29/2013 06:51 PM, John W. Eaton wrote:

OK, so we need to track down all the uses of ln and change them to
$(LN) or $(LN_S) and set those variables appropriately in the Makefile
depending on whether we are building natively on Windows.

I made this change.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3
I take that back - the issue is still the same (it tries to run tools/config.guess from the source folder of the application that is being compiled, which it cant find - needs the TOP_DIR ?

On Thu, May 30, 2013 at 4:13 PM, John Donoghue <[hidden email]> wrote:
I just tried a native build and it failed to compile binutils - the issue is the autodetect of target, which needs to change to:

TARGET := $(`tools/config.guess`)

 
On Thu, May 30, 2013 at 1:32 PM, John W. Eaton <[hidden email]> wrote:
On 05/29/2013 06:51 PM, John W. Eaton wrote:

OK, so we need to track down all the uses of ln and change them to
$(LN) or $(LN_S) and set those variables appropriately in the Makefile
depending on whether we are building natively on Windows.

I made this change.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
On 05/30/2013 04:16 PM, John Donoghue wrote:
> I take that back - the issue is still the same (it tries to run
> tools/config.guess from the source folder of the application that is
> being compiled, which it cant find - needs the TOP_DIR ?

The intent is to have it set once.  I guess it needs to use $(shell ...)
for that in addition to :=.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3


On Thu, May 30, 2013 at 4:19 PM, John W. Eaton <[hidden email]> wrote:
On 05/30/2013 04:16 PM, John Donoghue wrote:
I take that back - the issue is still the same (it tries to run
tools/config.guess from the source folder of the application that is
being compiled, which it cant find - needs the TOP_DIR ?

The intent is to have it set once.  I guess it needs to use $(shell ...) for that in addition to :=.

jwe


 
$(shell tools/config.guess) works for me
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

Clemens Buchacher
In reply to this post by John W. Eaton
On Tue, May 28, 2013 at 05:36:21PM -0400, John W. Eaton wrote:
>
> If you want to attempt a native build, edit the settings at the top
> of the top-level Makefile.

Thank you. This will be very useful. I am trying this on RHEL 5.8 with:

MXE_SYSTEM := gnu-linux
MXE_NATIVE_BUILD := yes
USE_SYTEM_GCC := no

But I get the following error while building gcc:

/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/./gcc/xgcc -B/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/./gcc/ -B/home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/bin/ -B/home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/lib/ -isystem /home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/include -isystem /home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/sys-include    -g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic -I. -I. -I../../.././gcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/. -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/../gcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/../include -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/gthr.h:150:0,
                 from /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/unwind-dw2.c:38:
./gthr-default.h:541:21: fatal error: windows.h: No such file or directory
compilation terminated.
make[7]: *** [unwind-dw2.o] Error 1
make[7]: Leaving directory `/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/x86_64-unknown-linux-gnu/32/libgcc'

Is this supposed to work? If so I can investigate further. Otherwise
(and in the meantime) I will try to use the system GCC (version 4.1.2 in
this case).

Next error I am looking into is in build-only-arpack:
configure: error: Cannot find BLAS libraries

Somehow I ended up building Octave on really old and new systems at the
same time...

Clemens
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
On 06/02/2013 08:30 AM, Clemens Buchacher wrote:

> On Tue, May 28, 2013 at 05:36:21PM -0400, John W. Eaton wrote:
>>
>> If you want to attempt a native build, edit the settings at the top
>> of the top-level Makefile.
>
> Thank you. This will be very useful. I am trying this on RHEL 5.8 with:
>
> MXE_SYSTEM := gnu-linux
> MXE_NATIVE_BUILD := yes
> USE_SYTEM_GCC := no
>
> But I get the following error while building gcc:
>
> /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/./gcc/xgcc -B/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/./gcc/ -B/home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/bin/ -B/home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/lib/ -isystem /home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/include -isystem /home/drizzd/src/mxe-octave/usr/x86_64-unknown-linux-gnu/sys-include    -g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic -I. -I. -I../../.././gcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/. -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/../gcc -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/../include -I/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/config/libbid -DENABLE_DECIMAL_BID
 _FORMAT -
DHAVE_CC_TLS  -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
> In file included from /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/gthr.h:150:0,
>                   from /home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2/libgcc/unwind-dw2.c:38:
> ./gthr-default.h:541:21: fatal error: windows.h: No such file or directory
> compilation terminated.
> make[7]: *** [unwind-dw2.o] Error 1
> make[7]: Leaving directory `/home/drizzd/src/mxe-octave/tmp-gcc/gcc-4.7.2.build/x86_64-unknown-linux-gnu/32/libgcc'

That error happens because there are some configure options in the
src/gcc.mk file that only make sense for Windows systems.  I'm working
on a patch that fixes that problem, but even so, I have not been
successful building GCC and then using it to build Octave for on any
system other than cross MinGW.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3
Ive been playing with trying to compile using mxe-octave on mingw this weekend: MXE_SYSTEM=mingw MXE_NATIVE_BUILD=yes USE_SYSTEM_GCC=yes
 
I didn't get far :)
 
All the build-xxx tools seem to install ok, with the exception of flex, so I skipped it and installed msys-flex.
 
lapack had issues with not being able to find ar and ranlib - it looks like they need be full _path_ names rather than just the ar/ranlib name in order to be used by cmake - I removed the AR/RANLIB in the mk file.
 
cmake also kept trying to pull in visual studio stuff even though it wasn't in the path, until I specified -G 'MSYS Makefiles'
 
For some reason it also wouldn't install the libraries, even though it displayed 'Installing liblapack.dll' etc
I had to add explicit install lines to the mk file in order to install the .dll, dll.a and lapack.pc file.
 
arpack wouldn't untar due to invalid links in the file - an update to 3.1.3 fixed that (I pushed the change for this)
 
nettle installed ok
 
gnutls has issues with not being able to link correctly ith a lot of errors such as undefined reference to gnutls_certificate_get_peers ...
I tried updating to the latest gnutls on the off chance that would help (which then forced an update to nettle) but got the same undefined reference issues.
 
And that was about as far as I got.


 
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John Donoghue-3


On Sun, Jun 2, 2013 at 8:50 PM, John Donoghue <[hidden email]> wrote:
Ive been playing with trying to compile using mxe-octave on mingw this weekend: MXE_SYSTEM=mingw MXE_NATIVE_BUILD=yes USE_SYSTEM_GCC=yes
 
I didn't get far :)
 
All the build-xxx tools seem to install ok, with the exception of flex, so I skipped it and installed msys-flex.
 
lapack had issues with not being able to find ar and ranlib - it looks like they need be full _path_ names rather than just the ar/ranlib name in order to be used by cmake - I removed the AR/RANLIB in the mk file.
 
cmake also kept trying to pull in visual studio stuff even though it wasn't in the path, until I specified -G 'MSYS Makefiles'
 
For some reason it also wouldn't install the libraries, even though it displayed 'Installing liblapack.dll' etc
I had to add explicit install lines to the mk file in order to install the .dll, dll.a and lapack.pc file.
 
arpack wouldn't untar due to invalid links in the file - an update to 3.1.3 fixed that (I pushed the change for this)
 
nettle installed ok
 
gnutls has issues with not being able to link correctly ith a lot of errors such as undefined reference to gnutls_certificate_get_peers ...
I tried updating to the latest gnutls on the off chance that would help (which then forced an update to nettle) but got the same undefined reference issues.
 
And that was about as far as I got.


 

Another update - I have managed to compile everything (well almost) up until octav, using mingw, and some mods to .mk files.
 
I am using a native install of Qt, rather than compiling QT and its dependancies, and was using the system gcc.
 
When it gets to compiling octave, it has issues in configure, not being able to find some functiosn from libgcc.
 
I did try build a native gcc in mingw from gcc.mk but had no luck and couldnt work out really what was wrong with it.
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

PhilipNienhuis
John Donoghue-2 wrote
On Sun, Jun 2, 2013 at 8:50 PM, John Donoghue <[hidden email]
> wrote:

>  Ive been playing with trying to compile using mxe-octave on mingw this
> weekend: MXE_SYSTEM=mingw MXE_NATIVE_BUILD=yes USE_SYSTEM_GCC=yes
>
> I didn't get far :)
>
> All the build-xxx tools seem to install ok, with the exception of flex, so
> I skipped it and installed msys-flex.
>
> lapack had issues with not being able to find ar and ranlib - it looks
> like they need be full _path_ names rather than just the ar/ranlib name in
> order to be used by cmake - I removed the AR/RANLIB in the mk file.
>
> cmake also kept trying to pull in visual studio stuff even though it
> wasn't in the path, until I specified -G 'MSYS Makefiles'
>
> For some reason it also wouldn't install the libraries, even though it
> displayed 'Installing liblapack.dll' etc
> I had to add explicit install lines to the mk file in order to install the
> .dll, dll.a and lapack.pc file.
>
> arpack wouldn't untar due to invalid links in the file - an update to
> 3.1.3 fixed that (I pushed the change for this)
>
> nettle installed ok
>
> gnutls has issues with not being able to link correctly ith a lot of
> errors such as undefined reference to gnutls_certificate_get_peers ...
> I tried updating to the latest gnutls on the off chance that would help
> (which then forced an update to nettle) but got the same undefined
> reference issues.
>
> And that was about as far as I got.
>
>
>
>

Another update - I have managed to compile everything (well almost) up
until octav, using mingw, and some mods to .mk files.

I am using a native install of Qt, rather than compiling QT and its
dependancies, and was using the system gcc.
Which version? 4.6.2?

When it gets to compiling octave, it has issues in configure, not being
able to find some functiosn from libgcc.
You get message like "undefined reference to `vtable for octave_base_value'" ?

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
In reply to this post by John Donoghue-3
On 06/02/2013 08:50 PM, John Donoghue wrote:
> Ive been playing with trying to compile using mxe-octave on mingw this
> weekend: MXE_SYSTEM=mingw MXE_NATIVE_BUILD=yes USE_SYSTEM_GCC=yes
> I didn't get far :)
> All the build-xxx tools seem to install ok, with the exception of flex,
> so I skipped it and installed msys-flex.

Hmm, I saw an error when building build-autoconf about the version of
m4.  Adding a build-m4 package (not yet checked in) seemed to get me
past that problem, but then building the build-autoconf package failed
with errors like this:

   Making all in m4sugar
   make[5]: Entering directory
`/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69.build/lib/m4sugar'
 
autom4te_perllibdir='/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69'/lib
AUTOM4TE_CFG='../../lib/autom4te.cfg'         ../../bin/autom4te -B
'../..'/lib -B
'/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69'/lib
        \
                   --language=m4sugar \
                   --freeze \
                   --output=m4sugar.m4f
   autom4te: freezing produced output:
   autom4te:
   ...
   ... many more lines like this
   ...
   autom4te:
   make[5]: *** [m4sugar.m4f] Error 1


You are not seeing this problem?  I have no clue what's causing it.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]

John W. Eaton
Administrator
On 06/06/2013 07:16 PM, John W. Eaton wrote:

> On 06/02/2013 08:50 PM, John Donoghue wrote:
>> Ive been playing with trying to compile using mxe-octave on mingw this
>> weekend: MXE_SYSTEM=mingw MXE_NATIVE_BUILD=yes USE_SYSTEM_GCC=yes
>> I didn't get far :)
>> All the build-xxx tools seem to install ok, with the exception of flex,
>> so I skipped it and installed msys-flex.
>
> Hmm, I saw an error when building build-autoconf about the version of
> m4. Adding a build-m4 package (not yet checked in) seemed to get me past
> that problem, but then building the build-autoconf package failed with
> errors like this:
>
> Making all in m4sugar
> make[5]: Entering directory
> `/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69.build/lib/m4sugar'
>
>
> autom4te_perllibdir='/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69'/lib
> AUTOM4TE_CFG='../../lib/autom4te.cfg' ../../bin/autom4te -B '../..'/lib
> -B '/c/Users/jwe/Desktop/mxe-octave/tmp-build-autoconf/autoconf-2.69'/lib \
> --language=m4sugar \
> --freeze \
> --output=m4sugar.m4f
> autom4te: freezing produced output:
> autom4te:
> ...
> ... many more lines like this
> ...
> autom4te:
> make[5]: *** [m4sugar.m4f] Error 1
>
>
> You are not seeing this problem? I have no clue what's causing it.

I should add that this happens for me when trying to build on a freshly
installed MinGW system, not while cross compiling.

jwe
1234