Fri 20 Feb 2015 01:10:21 AM UTC, comment #28:
Pushed http://hg.octave.org/mxe-octave/rev/7e15ef9bf1e5 and closing report.
|
Tue 17 Feb 2015 07:51:53 PM UTC, comment #27:
ok - doing a new build - will push if all goes ok again.
I am also trying a mingw 64 bit ghostscript which I will push as well if it succeeds
|
Tue 17 Feb 2015 07:42:48 PM UTC, comment #26:
It's OK with me if you go ahead and push it.
Thanks.
|
Tue 17 Feb 2015 07:01:14 PM UTC, comment #25:
Any issues if I push this up?
|
Sun 15 Feb 2015 02:02:22 PM UTC, comment #24:
Initial patch for multilib gcc, nsis in a 64 bit cross mingw environment.
(file #33080)
|
Sat 07 Feb 2015 11:18:37 PM UTC, comment #23:
For those that are interested, heres a script that creates a multilib gcc
At the moment it does not work if the prefix and sysroot are not the same, which is what we have in mxe-octave.
A few minor mods are required to nsis to build with it. I have been trying to get it to work with different prefix and sysroot without luck so far.
(file #33030)
|
Sun 01 Feb 2015 07:47:44 PM UTC, comment #22:
I just managed to build a multilib gcc by hand and compile nsis with it.
I will see if I can get into mxe.
|
Wed 28 Jan 2015 07:04:23 PM UTC, comment #21:
Oh, well, that too. I guess I didn't know it was possible.
|
Wed 28 Jan 2015 06:56:07 PM UTC, comment #20:
Or we get a gcc build working that does combo 32 & 64
|
Wed 28 Jan 2015 06:55:49 PM UTC, comment #19:
Wasteful or the correct and more reliable solution?
In my experience, it is far simpler to write rules that build things from scratch than it is to write rules that deal with generated files stored in a cache of some kind and try to make sure that they are properly up to date but not rebuilt unless that is what is really wanted, etc.
|
Wed 28 Jan 2015 06:39:35 PM UTC, comment #18:
Yes I knew you would say that, and obviously you're right.
AFAICS it would be only for nsis / makensis that a 32-bit toolchain is required, which looks a bit wasteful to me.
I can make do very will with the trick outlined in comments #10 en #12, symlinking works fine.
|
Tue 27 Jan 2015 09:17:43 PM UTC, comment #17:
I'd rather avoid putting compiled files into the hg archive.
I believe that the current upstream MXE project has the capability to build for multiple architectures in parallel. Using such a setup it would be possible to build the 32-bit NSIS installer and whatever tools are needed to build it along with the 64-bit compiler and tools for Octave.
|
Tue 27 Jan 2015 01:51:58 PM UTC, comment #16:
I've pushed some changes for libuuid and portaudio
|
Mon 26 Jan 2015 06:36:06 PM UTC, comment #15:
@comment #13
Could the stubs be pre-built separately and be provided in the mxe-octave mercurial repo?
|
Mon 26 Jan 2015 02:41:14 PM UTC, comment #14:
For the nsis failure because of uuid, it appears that portaudio is the problem child forcing the use of the dll.a for building octave.
If I change the pkg-config file for portaudio to not require uuid it appears to compile and run audio fine.
So will make some changes to portaudio for that and not install the dll.a file and hopefully nsis will be happy once again.
|
Mon 26 Jan 2015 01:32:47 PM UTC, comment #13:
It requires the cross compiler for making the stubs, even though it makes native binaries.
So it would need to build the native i686 cross compiler to build nsis, unless we can get the prebuilt stubs elsewhere.
|
Mon 26 Jan 2015 12:35:06 PM UTC, comment #12:
Yes same at my PCs too.
Anyway the trick of "transplanting" the 32-bit nsis fully works; 64-bit builds install and run fine on Windows 7 (that is, I haven't seen any adverse effects yet). Uninstalling also works.
I think my next step would be to simply symlink nsis (manually) across the 32-bit and 64-bit mxe-octave build directories.
I'm not sure, but I get the impression that nsis is built as a "native" executable by the tool chain, isn't it? If that's true, chances are that it can be built with the native build tools, just like the cross-compiler. This would also hold for native builds. That way the entire issue of both 32- and 64-bit build tools in the mxe tree just to build nsis for 64-bit Octave could be avoided in the first place.
Perhaps it is possible to simply build nsis as one of the first packages in a 32-bit setup, and only then reconfigure for 64-bit and build the other deps and 64-bit Octave. Renaming the makensis executable is required then.
|
Sun 25 Jan 2015 11:22:02 PM UTC, comment #11:
On my system, if I run make nsis-installer on a clean build, nsis gets built before blas, so if one of the first after the build-* packages.
|
Sun 25 Jan 2015 10:56:54 PM UTC, comment #10:
Well, so nsis in in the first batch of packages .... (I mean before libmng where my mxe builds usually break and I have to temporarily specify JOBS=1 to get libmng built).
Anyway the trick of copying nsis over to make a 32-bit installer for 64-bit Octave works.
I copied (from 32-bit mxe-octave tree to a 64-bit mxe-octave tree):
- ./usr/bin/makensis & ./usr/bin/i686-w64-mingw32-makensis to ./usr/bin/makensis and ./usr/bin/x86_64-w64-mingw32-makensis, resp.
(watch out for the latter's prefix; it's a 32-bit executable but needs a 64-bit prefix as that's the prefix expected by binary_dist_files.mk)
- ./usr/i686-w64-mingw32/share/nsis/ to ./usr/i686-w64-mingw32/share/nsis/
- ./installed_packages/nsis to ./installed_packages/nsis
same names for the last two files/dirs)
and with this trickery at least the installer is generated fine.
Whether it'll work on the Windows side is yet unknown, I'll see tomorrow; but I suppose if there are issues at all it's merely a matter of adapting the makeinst.sh script to include the relevant 64-bit options. I scanned the script but didn't spot any candidate stanzas yet.
|
Sun 25 Jan 2015 05:06:56 PM UTC, comment #9:
IIRC nsis is one of the last packages to be built, no?
So perhaps nsis.mk can have a stanza to first move libuuid.dll.a out of the way - temporarily or finally.
As to the 64-bit stuff, the link I provided in comment #7 has some pointers to script modifications that may be required for nsis on 64-bit systems with 64-bit apps.
Once my 32-bit mxe build is finished (usually takes 1.5 hours here) I'll have a go with nsis transplantation.
|
Sun 25 Jan 2015 12:18:14 PM UTC, comment #8:
no - I believe its the enable-windows-64 that makes it fail for nsis.
For libuuid.dll, it appears to require .dll.a for octave to build (actually portaudio needs it)
But nsis doesn't appear to like to.
Running a build that doesn't recompile nsis after building uuid will work. Just not rebuilding nsis after it.
I will play around with it some more.
|
Sun 25 Jan 2015 11:15:18 AM UTC, comment #7:
@John D:
I was building with --enable-windows-64, is that also not possible? I figured only the --enable-64 option would prevent NSIS from building. Oh well.
I think I'll experiment with transplanting the NSIS libs etc from a 32-bit build; I've done that sort of gross hacks before and sometimes it even works :-)
|
Sun 25 Jan 2015 04:36:57 AM UTC, comment #6:
I have compiled for win32.
deleting libuuid.dll.a fixed the problem, but them
I have a problem with postgresql, so I decided to build mxe-octave from scratch. But it failed on gcc-gmp-download, because it has a version change, from 6.0.0 to 6.0.0a.
|
Sun 25 Jan 2015 01:39:51 AM UTC, comment #5:
Philip,
I think you are compiling for win 64.
|
Sat 24 Jan 2015 11:40:52 PM UTC, comment #4:
I'll put up my nsis log file.
I see different errors than Avinoam.
(file #32907)
|
Sat 24 Jan 2015 11:37:05 PM UTC, comment #3:
No that doesn't do it :-(
|
Sat 24 Jan 2015 11:35:24 PM UTC, comment #2:
Confirmed here.
I see no libuuid.dll.a, only libuuid.a in mxe-octave/usr/x86_64-64-ming32lib and ..../lib32.
Is it safe to delete them? (I'll first try with renaming them)
|
Sat 24 Jan 2015 07:24:56 PM UTC, comment #1:
Try deleting libuuid.dll.a from mxe-octave/usr/i686-xxxxxxxx/lib
|
Sat 24 Jan 2015 08:20:18 AM UTC, original submission:
building mxe-octave on Ubuntu I get "Failed to build package nsis"
last lines of log file:
full nsis log attached.
Thanks
|