MakeNSIS 2.50 Compile on CentOS7

Hi All--

I'm attempting to create a new build machine for my products to replace a dying one. I've downloaded the NSIS 2.50 source and am attempting to compile it. I've applied a patch to get around a gcc 4.8 compile issue, but now I'm getting a link error:

/bin/ld: i386 architecture of input file `build/release/makensis/build.o' is incompatible with i386:x86-64 output

/bin/ld: i386 architecture of input file `build/release/makensis/clzma.o' is incompatible with i386:x86-64 output

/bin/ld: i386 architecture of input file `build/release/makensis/crc32.o' is incompatible with i386:x86-64 output

....

collect2: error: ld returned 1 exit status

scons: *** [build/release/makensis/makensis] Error 1

scons: building terminated because of errors.

As near as I can tell, the compile is getting done with the -m32 flag as it should.

I've made sure I have the 32-bit development libraries installed. Can someone help me get past this?

Thanks!

CrazyDogGuy

I guess you need to pass "-m elf_i386" to the linker?

Have you tried NSIS v3? v2.xx is probably harder to get working on newer systems...

Thanks for the response, Anders.

We can't update to 3.0 yet, we'd have to update a bunch of custom plugins and do a bunch of testing that we don't have the time for at the moment.

I did figure out my problem... there was a clue a little earlier in the log:

Using GNU tools configuration

Checking for compiler flag -m32... (cached) yes

Checking for linker flag -m32... (cached) no

That led me to add the following to $SRCDIR/SCons/Config/gnu in the makensis environment section:

makensis_env.Append(LINKFLAGS = ['-m32'])

Incidentally, for anyone else that attempts this with 2.5 and GCC later than 4.6, you'll get a compile error before you ever get to the linker if you don't apply the changes in this patch

Thanks again for the help,
CDG

Originally Posted by CrazyDogGuy View Post

We can't update to 3.0 yet, we'd have to update a bunch of custom plugins and do a bunch of testing that we don't have the time for at the moment.

The plugin API hasn't changed, but there is a new restriction on where you can load .dll's from (%windir%\system32 and $pluginsdir are the default, you can add more with AddDllDirectory() using the system plugin).

FYI, many of the example scripts in 2.46 haven't been changed in 3.0, so there is a pretty good chance the script itself will compile without errors.

Originally Posted by JasonFriday13 View Post

The plugin API hasn't changed, but there is a new restriction on where you can load .dll's from (%windir%\system32 and $pluginsdir are the default, you can add more with AddDllDirectory() using the system plugin).

No, only system32 is searched by default, you have to add $pluginsdir with AddDllDirectory if you need it but all of this only applies to relative paths, absolute paths work everywhere. If your plug-in only uses normal Windows .dlls like user32 and shell32 then you don't have to do anything.

When you move to 3.0 you probably want to switch to Unicode as well and that might mean fixing bugs in your plug-in that usually show up when you first switch even if it was coded with TCHAR/LPTSTR/TEXT to begin with. If you stay Ansi then 3.0 and 2.5x are very similar.