Tian_GCfilms
8th April 2005 20:13 UTC

Linux makensis generated a bad Windows installer
Hello,

I am project manager of GCfilms. This application is written in Gtk2-Perl and can be used to manage a movie collection.

We created a Windows installer using NSIS and it works perfectly when generated from a Windows system.

We managed to compile a Linux version of makensis that seems to work well also. But when generating the installer from a Linux system, it has a weird behaviour.

Installation began normally with language selection. Then we added a Perl detection to check if this dependancy is installed. This also works fine. But then the installer stops without error message (even when launched from an MS-DOS console).

Of course, we used the same .nsi file for both generations. It can be seen in our CVS repository:

http://cvs.gna.org/viewcvs/gcfilms/g...32/gcfilms.nsi

I also attach it to this thread.

Did someone already experience this kind of problem? Is there a way to have more information about the crash reasons?

Any help would be really appreciated. As we all use GNU/Linux system, it would be great if we could generate the Windows installer from this system.

Thanks a lot,

Tian.

Tian_GCfilms
8th April 2005 21:25 UTC

Hum I think I got it. I commented 2 lines and everything seems to be OK now. They are:

;!define MUI_ICON "${NSISDIR}/Contrib/Graphics/Icons/orange-install.ico"
;!define MUI_UNICON "${NSISDIR}/Contrib/Graphics/Icons/orange-uninstall.ico"

(using / or \ in paths didn't change anything)

Really strange.

Does someone have any idea about that as it could in fact hide a more important problem?

kichik
9th April 2005 11:36 UTC

I tried compiling your installer on Linux with NSIS 2.06 and everything worked fine. I have only tested it up until the components page, as it stopped before the main dialog was even shown in your test.

I had to modify the script a bit so it'll compile. I removed File instructions, changed the license path and fixed the case of the WinMessages.nsh include. The modified script is attached.

Which NSIS version did you use to compile the script? Did you use the precompiled exeheads or did you compile them using a cross compiler? If you compile the modified script, does it work well? If it doesn't, can you attach the installer itself?

Tian_GCfilms
9th April 2005 17:06 UTC

Thanks a lot for your help.

I had to modify the script a bit so it'll compile. I removed File instructions, changed the license path and fixed the case of the WinMessages.nsh include. The modified script is attached.

Which NSIS version did you use to compile the script? Did you use the precompiled exeheads or did you compile them using a cross compiler?

kichik
9th April 2005 17:32 UTC

If you've used the cross compiler, that's probably the problem. I'll try to debug it a bit. In the meanwhile, you can compile it with the precompiled exeheads. It's better anyway since VC6 produces way smaller executables than MinGW. Don't foget to extract the original source archive again so you'll get the header files back.

I might also need the compiled makensis that produced this installer, so please save a copy of it.

Tian_GCfilms
9th April 2005 18:23 UTC

I tried to generate again using this command

make USE_PRECOMPILED_EXEHEADS=1

And now it works perfectly (even with the icons lines). So it seems to be because of cross compiler as you expected.

I still have everything from previous installation. So just let me know if you something.

Thanks again for time you spent helping us.

kichik
4th August 2005 20:46 UTC

Short version:

There's a bug in the build process, when MinGW is used.

Long version:

After playing around with the installer a bit more, I found that by removing a very certain number of dialog items, I can make the installer work again. It has the same effect of using the smaller icon, like you've mentioned in your first post. It reduces the resource section (.rsrc) size. The problem with the size is that the .ndata section follows the .rsrc section. .rsrc should precede the .ndata so editing the resources won't move .ndata. The location of .ndata is used in code which writes to it. When the .rsrc section grew over .ndata, this code overwrote the resources with other data. By reducing the .rsrc section size, with the smaller icon or less dialog items, the .ndata section was returned to its original place, given to it at linkage time.

I don't know why .ndata followed .rsrc instead of preceding it in your compiled version. There's a linker script that's supposed to set the correct order of the sections. Actually, I've just tried compiling on my own using MinGW, and it put the .ndata section last too. I'll have to dig into it a bit more to find out how to get it to order the sections correctly.