octave-maintainers
[Top][All Lists]
Advanced

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

Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-install


From: Philip Nienhuis
Subject: Re: Building on MinGW using MXE-built dependencies [WAS: Re: mxe-installer try 2]
Date: Tue, 11 Jun 2013 22:18:51 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

John W. Eaton wrote:
On 06/11/2013 03:43 PM, Philip Nienhuis wrote:
John W. Eaton wrote:
On 06/11/2013 02:51 PM, Philip Nienhuis wrote:

Here I didn't even get as far as you did. I installed mingw + above
dependencies, updated/upgraded, cloned mxe-octave.
The mxe build breaks while building gcc.

That's not currently expected to work. I've not been able to get gcc to
build for any native build setup. So you need to try with USE_SYSTEM_GCC
set to yes.

Stupid me, I could have seen that myself, didn't think of reading that
far into Makefile. Sorry.

Anyway, I changed USE_SYSTEM_GCC to "yes" but now ./mk-dist insists on
building gcc. How can I avoid that?

Philip

Are you sure it is actually building GCC? It will still unpack and run
the build target, but if you look at gcc.mk, you'll see that when
USE_SYSTEM_GCC is set to yes, it will only create a cmake configuration
file, not actually build the compiler.

Hmmm, so the message "[build] gcc" (and the long period of hard disk activity) is a bit deceptive....

But I saw you are correct, it started building blas and now lapack.

Fixing the Makefile to avoid
unpacking the gcc tar file when it won't be used is on my list but I
haven't done it yet.

I fear that list is long :-)

On my list is finding out how to build using mxe-octave on Windows 7 64-bit, as that runs on my fastest dev box (the build I referred to runs on an older Core Duo desktop). I consistently get configure messages that "gcc cannot build executables", with the log mentioning that ld cannot find a.o., -ladvapi32. Now, advapi32.dll and friends are in the C:\Windows\system32 dir which *is* in the MinGW PATH as /c/windows/system32. I've experimented with LDFLAGS and other tricks to no avail :-) Google didn't turn up a solution yet.
I think this is a very MinGW-specific issue.

Thanks,

Philip


reply via email to

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