I build it by cleaning the directory and then using a command line of scons. I tried this using various versions of Visual Studio. By default, it is 12.0. I set MSVS_VERSION to build with other versions.

#1 I have not researched this error yet.
#2 I found a few posts about this, but none provided a solution. I've checked that zlib.h, zdll.lib and zlib1.lib are where they are expected.
#3 The unresolved __hypot is because of a change in the library starting with VS 2010. I suspect that __fltused is a similar problem.

I have tried this on a second computer with a similar setup. The results are the same.

Which SDK are you using with VC toolkit 2003? Platform SDK 2003 Feb. is probably your best bet.

1) SCons is probably not able to find the lib?2) Are you sure ZLIB_W32 is set correctly? Use File Monitor/Process Monitor to make sure SCons is actually looking in the right place.3) Newer versions of VS are probably doing something stupid. MakeLangId does not use floating point numbers nor any other CRT function.

I can build with VCTK2003 but I'm using a backdoor to override the Scons VS detection:

I'm using SCons v1.2.0.r3842 because newer versions never work correctly for me. (Having multiple SDK's and versions of VS on the same machine is not a good idea when trying to fix these build errors)

When using MSVC_USE_SCRIPT=None the PATH, INCLUDE and LIB environment variables have to be set correctly (Use the shortcuts created by the Platform SDK: Windows 2000/XP Release 32-bit etc). Specifically it needs to be able to find cl.exe, link.exe and lib.exe in %PATH% and Windows.h in %INCLUDE%.

I'm using SKIPPLUGINS=System because I did not have the MASM assembler (ml.exe) in %PATH%.

I would generally not recommend that people use MSVC_USE_SCRIPT but it can be helpful if you cannot get SCons to operate correctly. It seems to be a rather undocumented parameter and depends on your SCons version. If you also use MSTOOLKIT=yes then it will use our custom implementation of this feature (YMMV).

It is important that you delete .sconsign.dblite and the .sconf_temp directory when trying to fix the libcp.lib and zlib errors because SCons caches config data. Checking config.log might also provide some clues...

im in the same alley struggling to get NSIS to compile without errors,
assuming i have nothing installed; can someone please sort these out for me,
which of these do i want to use to get a successful build?

Thank you Andres,
I am actually trying again on a new virgin PC because I was getting errors on my other machine,
I do use it for other development; I already have VS2012; I have all path in place on both machines;
with Python installed scones v1.20 and wxMSW v2.8; I am getting a warring on both machines,
and on both compilation stops due to fatal errors,

the one machine W7 has VS2012 with latest scones build and newer wxMSW
I got similar errors as OP described; on my other box its xp,
I’m setting up now VS6 with SP5 and proc pack with older scones and wxMSW to see if this helps,

No switches were initially used; though I have tried several with no joy,

Try adding SKIPUTILS=MakeLangId as a scons parameter. (MakeLangId is a simple program and does not use floats but as you can see, it is rather hard to keep all visual studio versions happy at the same time)

i think the buffer was enough to hold all the log;
the first line should have the command i run as well

i run from -> d:\dev\nsis\
in this last run i had -> scons SKIPUTILS="MakeLangId","NSIS Menu"

other directories needed are here and referenced in path
d:\dev\wxWidgets\
d:\dev\zlib-1.2.7\
C:\Python27\
in this last run i had

im not sure yet if im doing something to add to this odd behavior;
scons doesn't like to work nicely on my Win7 pc for some odd reason,

i run it few times from a normal command window;
until it just refused to be recognized; jut like that!
no changes made other then close and open a new command window;

it didn't matter that i removed and installed it back; python is in path as needed,
i added direct path reference to \site packages\scons\
i did just about everything i can think of to make sure everything is visible;
yet scons remained un recognized; i had to pull VS command and work through it,

You installed python in it's default directory right? Which would be C:\Python27? Add C:\Python27\scripts into the environment's system path. Then in a command window all you have to do is change to the nsis directory and run your scons command.

Why do you even need to build NSIS? If you cannot piece together the information you have already gotten to get past the MakeLangId problem then I don't understand how you are going to be able to make any meaningful changes to the source...

Alright, close that window that failed. Now use your original scons command line on the new window.

Because the command window doesn't pickup changes in the environment, it's advised to only have one command window open at any time, and close and open a new window after each change. On ubuntu it doesn't matter, I can have one command window open and I can add and remove path variables and programs, and the command window can still pick them up, and it remembers every command you type into it .

[edit] Just saw Ander's reply, that's a good point, I didn't have this much trouble compiling NSIS, I use VS2008 and I skip the help file and NSIS Menu. I've done this on windows 7 and windows 10.

I noticed VS version 12 in the scons output, do you have VS2013/VS2015 installed by any chance?

I've been thinking about it, but really I don't want to. The trunk build has had some major changes done to it since my fork, and I don't really want to maintain a fork that's probably going to be discarded in the future anyway (because technology keeps moving on).

why would it be discard in future releases; this is crucial today!
if anything this should be further enhanced and supported, im shocked to find out this 2GB limit,
everyone moving towards 64bit more ram; more speeds; while NSIS is stuck with FAT16 limits?
shocked, stunned, extremely disappointed; i will likely be looking for another solution ,

did you manage to fix the few loss end he originally left with compression and such?

The limit has been in place for a good ten years now, and there have been people over the years that have requested this limit be removed (myself included). The devs are a bit reluctant to add support, the patches shown so far aren't really 'nice' enough to be integrated.

My fork just adds to what's already there, I haven't removed anything from the original source. The only downside is that solid compression isn't supported, which is no biggie as it would just make the install slower.