NSIS compile error - NSIS Forums

lroathe
5th June 2004 03:40 UTC

Quote:

iceman_k
5th June 2004 04:00 UTC

Not that I know of.
I just tried compiling and it worked fine. I assume you are using the latest CVS version?

lroathe
5th June 2004 04:06 UTC

Trying to compile the latest from CVS, just checked it out this afternoon. The aullshr reference is in gui.c if that helps.

Actually, the only reason I want to compile is to modify the error message reported for "Corrupt Installation Detected" -- many of my users get this when downloading our products (they range from 25MB to 105MB in size) and it would be good if that message indicated it was probably a download problem and give a suggestion on how to solve it.

Can I otherwise modify this string?

kichik
5th June 2004 09:49 UTC

__aullshr is probably VC6 SP6's function that performs shift right operations on unsigned long long variables. No idea what the 'a' is for :)

Try replacing Ui.c line 907:

available = (int)(available64.QuadPart >> 10);

with:

available = (int)(Int64ShrlMod32(available64.QuadPart, 10));

lroathe
5th June 2004 17:16 UTC

Originally posted by kichik
__aullshr is probably VC6 SP6's function that performs shift right operations on unsigned long long variables. No idea what the 'a' is for :)

Try replacing Ui.c line 907:
available = (int)(available64.QuadPart >> 10);
with:
available = (int)(Int64ShrlMod32(available64.QuadPart, 10));

That was exactly the problem, and I can now compile and link all targets! Now, why the frick does my copy of VC6 SP6 generate a call to that function, but is then not able to link in that function? Could it be that there is a way to setup VC6 with long-long support libraries as an option?

Anyway, thanks for the help!

PS: my guess at the function name is "arithmatic unsigned long long shift right"

iceman_k
5th June 2004 18:32 UTC

Alternately, you can extract ullshr.obj from libc:


lib /extract:build\intel\st_obj\ullshr.obj libc.lib

and link it in the project.

iceman_k
2nd July 2004 16:33 UTC

Originally posted by kichik
__aullshr is probably VC6 SP6's function that performs shift right operations on unsigned long long variables. No idea what the 'a' is for :)

Try replacing Ui.c line 907:
available = (int)(available64.QuadPart >> 10);
with:
available = (int)(Int64ShrlMod32(available64.QuadPart, 10));

Any plans of making this change in the CVS source?

kichik
2nd July 2004 22:06 UTC

No. It produces larger code. A better solution must be found.

iceman_k
3rd July 2004 03:09 UTC

Is this of any use to you?
ullshr.asm

kichik
3rd July 2004 13:38 UTC

Hmm... Visual C++ Introductory Edition? I assume you meant to link to an implementation of ullshr. I prefer not to get assembler in yet. Extracting __aullshr as an .obj file and linking to it so SP6 can find does seem like a possible solution. I would, of course, prefer a code change solution that will both work on SP6 and SP5 and not increase code size.

iceman_k
3rd July 2004 19:54 UTC

Oops! :o
Certainly didn't mean to imply that you needed an intro to VC++.
Here is the correct link:
ullshr.asm

But, yes, it is assembly.
So, perhaps not the right solution for now.

RDaneel
3rd July 2004 20:32 UTC

Hmmm... going along with kichik, let's not be too hasty here. :)

I built from CVS on June 3 (because of the NT4 installer problem with GetDiskFreeSpaceEx), and this chunk of code dealing with the 64-bit right-shift is right there in the sources... and *I* used a vc6 SP6 system to do it.

BUT, I am still using the code generator (c2.dll) from the "Processor Pack" for SP5... and possibly because of the newer ["vc7"] compiler piece, all I see is inline code generated for the code sequence in question:

mov eax, DWORD PTR _available64$93998[ebp]
mov ecx, DWORD PTR _available64$93998[ebp+4]
shrd eax, ecx, 10
shr ecx, 10 ; 0000000aH

This is with the NSIS-standard optimization setting of "Minimize Size", BTW. However, I do specify the "Pentium Pro" (/G6) code generation option, since that more accurately reflects the in-use processor architectures one is like ly to see these days.

So, since as I recall, kichik uses the Processor Pack, this could explain why only some people are seeing this linking issue - the people who are not using the Processor Pack. :)

As to *why* the linking problem exists, it is not really clear to me - the "ullshr.asm" file has been part of the CRT sources for a long time - take a look in ..\CRT\SRC\Intel.

As for vc6 SP6 + the SP5 Processor Pack, I have been using this combination since SP6 came out with no difficulty. Besides not seeing any trouble myself, I might point out that SP6 does NOT include a new version of c2.dll, so the possibility of incompatible changes to the intermediate representation from the compiler's earlier passes is small. :)

iceman_k
3rd July 2004 22:22 UTC

Hmmm... I didn't try VS6 SP6 + SP5 processor pack.
Let me try that and see.

RDaneel
3rd July 2004 22:45 UTC

If you have any trouble doing this... SP6 *will* attempt to remove/disable the Processor Pack. :(

I took care of this by saving the contents of the appropriate "Bin" directory first, and then restoring any of the c2.dll / MASM support files I needed to after the SP6 update was done.

One could take this approach, or if the "damage" has already been done, using 7-Zip or WinZip to pull the relevant files straight out of the SP5 Processor Pack installer would probably be fine too. :)

Note that this all works fine if one just wants the superior code generator from the Processor Pack... if you want to actually use the processor Pack as MS intended (to have compiler support for the MMX/SSE etc H/W), there may be a little more environment needed to restore - see the .reg files in the PP installer, for example.

kichik
7th July 2004 18:01 UTC

Originally posted by RDaneel
As to *why* the linking problem exists, it is not really clear to me - the "ullshr.asm" file has been part of the CRT sources for a long time - take a look in ..\CRT\SRC\Intel.

We don't use CRT ;)

bluenet
1st October 2004 01:47 UTC

I got another error: NSIS\Source\DialogTemplate.cpp(353) : error C2065: 'DS_SHELLFONT' : undeclared identifier
What wrong for me? Compiler is VC++ 6 with SP6
I find it define in exehead\resource.h

I try to add

#ifndefDS_SHELLFONT

#defineDS_SHELLFONT(DS_SETFONT|DS_FIXEDSYS)

#endif

to DialogTemplate.h it compile OK. :D

kichik
1st October 2004 10:46 UTC

Fixed, thanks.

kichik
16th September 2005 17:27 UTC

I've added a check to the SConscript to check for this specific case and use Int64ShrlMod32 instead. Building using SP6 should no longer require manual intervention.

Wizou
17th March 2010 11:17 UTC

I have a problem building NSIS with MSVC 2005 tools:

as /coff -o build\debug\System\Source\Call.obj Contrib\System\Source\Call.S
'as' was not found.

After some investigation, I think the problem is that SCons should use masm.py configuration in order to use the ml.exe MASM compiler that comes with MSVC, instead of as.exe (from MingW?)

But I don't know how to tell SCons to do that..

kichik
22nd March 2010 15:33 UTC

Are you sure ml.exe is in the PATH? At least on VC6 it required a separate installation of the Processor Pack, iirc.

Wizou
23rd March 2010 10:10 UTC

thanks! after adding MSVC dir to the PATH, it worked

Originally posted by iceman_k
Make sure that you also have the latest Platform SDK downloaded.
Then register the PSDK directories with Visual Studio using the shortcuts installed with the PSDK.
Then try compiling again.
Maybe it will fix the problem. Unfortunately I had already done that. Does NSIS require .net?