Richard W.M. Jones <rjones <at> redhat.com> writes:
> It turns out that [NSIS is] not just built for 32 bit because of the
> general hideousness of the code, but because it builds Windows 32 bit
> plugins. Somehow -- and I've no idea how it does this -- the Windows
> plugins get loaded into the native Fedora binary at runtime.

Those plugins don't actually get loaded into the Fedora binary. They get packed
into the generated installer image.

> Even though the main binary is Fedora native, it still has to be built as
> 32 bit to achieve this minor miracle.

The Debian folks worked hard on making NSIS build as a true 64-bit binary, not
with -m32, and as far as I know their patches got merged upstream already.

The W32 plugins need to be built with the MinGW cross-compiler of course, not
the native compiler, so they aren't affected by this problem at all.

I can have a try at making a proper x86_64 package with the plugins actually
built from source. What I know is that my hack (packaging the binary plugins
from the prebuilt ZIP and rebuilding makensis from source as 64-bit) worked.

What's clear is that 32-bit binaries on a 64-bit system are not a solution, you
have to be very special like WINE to get away with this (and even WINE is not
built with -m32, it's simply copied from the i386 repo by a multilib whitelist
entry; fake x86_64 packages with 32-bit stuff in it are a bad idea), NSIS has
really no valid reason to use 32-bit binaries.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Oct 07, 2008 at 06:01:35PM +0100, Andrew Haley wrote:
> Weirder still. How does zlib get built anyway?

>From source using the MinGW cross-compiler.

http://fedoraproject.org/wiki/MinGW

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Oct 07, 2008 at 05:40:15PM +0000, Kevin Kofler wrote:
> Richard W.M. Jones <rjones <at> redhat.com> writes:
> > It turns out that [NSIS is] not just built for 32 bit because of the
> > general hideousness of the code, but because it builds Windows 32 bit
> > plugins. Somehow -- and I've no idea how it does this -- the Windows
> > plugins get loaded into the native Fedora binary at runtime.
>
> Those plugins don't actually get loaded into the Fedora binary. They get packed
> into the generated installer image.

Aha ... I'm glad someone knows what's going on here (not me :-)

I thought that the Stubs were copied into the output binary, but the
Plugins got loaded into the executable, but I seem to be wrong about
that.

> > Even though the main binary is Fedora native, it still has to be built as
> > 32 bit to achieve this minor miracle.
>
> The Debian folks worked hard on making NSIS build as a true 64-bit
> binary, not with -m32, and as far as I know their patches got merged
> upstream already. The W32 plugins need to be built with the MinGW
> cross-compiler of course, not the native compiler, so they aren't
> affected by this problem at all.

I'm actually using Debian's patch, but I rebased them against 2.39.
Debian is on 2.19 for reasons I can't determine, but 2.19 doesn't
build on Fedora (it looked like a gcc error, but I didn't examine it
in great detail, because the newer version builds fine).

> I can have a try at making a proper x86_64 package with the plugins
> actually built from source. What I know is that my hack (packaging
> the binary plugins from the prebuilt ZIP and rebuilding makensis
> from source as 64-bit) worked.

Please, and if you can supply patches against our repository, or I can
get you commit access, then all the better.

Of course, building anything from binaries isn't acceptable. It has
to be all built from source.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Oct 07, 2008 at 07:51:27PM +0100, Richard W.M. Jones wrote:
> Please, and if you can supply patches against our repository,

http://hg.et.redhat.com/misc/fedora-mingw--devel

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Richard W.M. Jones <rjones <at> redhat.com> writes:
> I'm actually using Debian's patch, but I rebased them against 2.39.
> Debian is on 2.19 for reasons I can't determine, but 2.19 doesn't
> build on Fedora (it looked like a gcc error, but I didn't examine it
> in great detail, because the newer version builds fine).

Hmmm, I've looked at the Debian experimental package (which is 2.39 - stable
works mostly like RHEL, with even stricter policies about version upgrades;
unstable and experimental are where all their development happens), but they
now switched to building with -m32 like upstream. :-(

The patch you used, on the other hand, is outdated, it was for a version before
upstream added the -m32, so it doesn't remove the -m32.

Try the 64bit-fixes patch in:
http://repo.calcforge.org/fedora/9/SRPMS/nsis-2.34-1.src.rpm
I also have a patch there to use the RPM_OPT_FLAGS, which is also important,
but might need fixing to not try to pass the RPM_OPT_FLAGS to the plugin
builds. (As I said, I haven't tried actually building the plugins yet.)

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Oct 08, 2008 at 09:36:44AM +0000, Kevin Kofler wrote:
> Try the 64bit-fixes patch in:
> http://repo.calcforge.org/fedora/9/SRPMS/nsis-2.34-1.src.rpm

That patch builds a 64 bit makensis, which is definitely an
improvement. However something still wants to link with the 32 bit
wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Richard W.M. Jones <rjones <at> redhat.com> writes:
> That patch builds a 64 bit makensis, which is definitely an
> improvement. However something still wants to link with the 32 bit
> wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

That's the menu stuff. I haven't tried building that one yet (it's disabled in
that SRPM - it's not essential to be able to use NSIS). Presumably there's also
a -m32 switch somewhere there which also has to be patched out? There may also
be 64-bit safety issues, I can help you with those. (I have some experience
with that sort of stuff, I had my own 64-bit patchset for NSIS originally, but
Debian eventually fixed the same stuff too so I used theirs, I was also the one
who fixed z88dk for 64-bit architectures.) The gist of it is to build on x86_64
with as many GCC warnings as possible and fix everything GCC complains about,
usually those are all the offending places, only rarely there is some stuff
which has to be noticed by hand (during runtime testing).

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Richard W.M. Jones <rjones <at> redhat.com> writes:
> That patch builds a 64 bit makensis, which is definitely an
> improvement. However something still wants to link with the 32 bit
> wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

I fixed that, and I also disabled the wxGTK menu app because it doesn't appear
to work on non-Window$. Disabling the menu also avoids having to drag in wxGTK
into something which is otherwise a plain command-line tool.

I sent you updated SRPMs in private mail, can you please merge my changes? (In
addition to the fixes, I'd also really like the Obsoletes/Provides for nsis and
nsis-data to go in.)

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list