Skip to content
⌘ NSIS Forum Archive

Building NSIS with vc9

39 posts

TobbeSweden#

Building NSIS with vc9

I'm trying to build NSIS with Python 2.5, scons 0.98.5 and vc9 but I get an error saying "Couldn't find a good version of libcp.lib". What am I doing wrong? I'm trying to build HEAD
kichik#
VC9 is probably not configured properly and so SCons can't tell it's using VC9 or SCons simply doesn't support VC9 yet. Clean the entire directory, run SCons again and look for the first error in config.log.
TobbeSweden#
This is the (translated) contents of config.log
file C:\Tobbe\DevProjects\C++\nsis\SCons\Config\ms,line 37:
Configure(confdir = .sconf_temp)
.sconf_temp\conftest_0.cpp <-
|
|#include <fstream>
|int main() {
| // no change
| std:😳fstream header("test", std:😳fstream:😳ut);
| return 0;
|}
|
cl /nologo /GS- /EHsc /TP /D_CRT_SECURE_NO_WARNINGS /D_CRT_NONSTDC_NO_WARNINGS /c .sconf_temp\conftest_0.cpp /Fo.sconf_temp\conftest_0.obj
cl is not an internal command, external command or command file.
If I try to run the cl command on my own I get this:
C:\Tobbe\DevProjects\C++\nsis>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
TobbeSweden#
Some clarification and more information:
I ran "scons" from a "Visual Studio 2008 Command Prompt" and that's where it gave me the above output when I tried to run cl.exe. Trying to run cl.exe from a "normal" command prompt it says it can't find cl.exe. So I added the path to cl.exe to %PATH%, rebooted the computer, and reran scons but still got the same error. Running cl.exe from a normal cmd prompt gave a different result though. Now I get a messagebox saying cl.exe can't find mspdb80.dll (it used to say it couldn't find cl.exe)
Joost Verburg#
SCons doesn't support Visual C++ 2008 yet. A temporary solution would be to use the environment variables to detect the compiler location. We did this for MSVC 2005 until support was added to Scons:

TobbeSweden#
I got much further now 🙂

Now I get this:
*** error: WXWIN must be set to build NSIS Menu!
scons: *** [build\release\NSIS Menu\NSIS] Error 1
scons: building terminated because of errors.
I don't (think) I want to compile NSIS Menu. How do I not compile it?
TobbeSweden#
I just added this to the beginning of SCons\Config\ms
import os

defenv['ENV']['PATH'] = os.environ.get('PATH')
defenv['ENV']['HOME'] = os.environ.get('HOME')
defenv['ENV']['LIB'] = os.environ.get('LIB')
defenv['ENV']['INCLUDE'] = os.environ.get('INCLUDE')
defenv.Append(CCFLAGS = '/GS-')
Since I just wanted to make it work on my computer I got rid of the "if defenv" stuff
Sheik#
Originally posted by TobbeSweden
I added SKIPUTILS="NSIS Menu"
Finished without errors now 🙂
BTW, the "NSIS Menu" util is a real pain to get compiled. It requires a lot of external things, and has to be done exactly right.

Its too bad it can't be made easier to build...
Anders#
Originally posted by Sheik
BTW, the "NSIS Menu" util is a real pain to get compiled. It requires a lot of external things, and has to be done exactly right.

Its too bad it can't be made easier to build...
Then again, its not something most people need to recompile
Comperio#
This is the first time I've tried to compile NSIS from source. (actually, this is also the first experience I've had with using Scons too.)

I seem to be having the same problem as the original thread: Error "couldn't find a good version of libcp.lib".

I've got Visual C++ 2008 Express, Python 2.5 and Scons 0.98.5 on a Windows XP SP3 box. I have confirmed that the file libcp.lib is NOWHERE on my system. (I search the entire local drive.)

one post says this:
SCons doesn't support Visual C++ 2008 yet. A temporary solution would be to use the environment variables to detect the compiler location.
I'm not sure if this is the fix, but I'm not sure what environment variables/values Joost is referring to. It looks like the issue was in fact resolved, but it wasn't clear to me how. 😕

Can someone help clarify?
Joost Verburg#
SCons still does not support MSVC 2008. You need to add the workaround TobbeSweden posted.
Comperio#
OK, I did as you recommended and now I'm getting this error:
scons: *** No SConstruct file found.
File "C:\Python25\Lib\site-packages\scons-0.98.5\SCons\Script\Main.py", line 817, in _main

I'm not sure how to decipher this. Do I maybe just need something added to my PATH variable?
Comperio#
Some more info:
I tried installing VC++ 2005 edition thinking that might help, but unfortunately it didn't.

After digging into the logs more, I found an error that Kernel32.lib was not found.

I fixed this by adding "C:\Program Files\Microsoft Visual Studio 8\VC\lib" to the end of my windows path statement (since that's where I found Kernel32.lib)

That seemed to get me further along, but now I'm getting this error:

AttributeError: 'NoneType' object has no attribute 'split':
File "C:\downloads\Development\__INSTALLATION\nsis\source\nsis-2.38-src\SConstruct", line 364:
I have attached a copy of my current MS file in case it might help.

Attachments

DaveMoll#
I'm also trying to build NSIS from source and running into similar problems. I need to rebuild Unicode NSIS with logging enabled for proper Japanese language support.

I am unable to get past the problem with not being able to find a good version of libcp. I tried the above modifications to the "ms" file, but didn't have any luck. I have VS2008, VS2005 as well as VC5 and 6 installed on my development machine.

If I make the modifications to the "ms" file (changing the defenv section as in Tobbe's post) I still see the "Couldn't find a good version of libcp.lib".

I'm not really familiar with scons or python (I've used ant more than make), could the wiki be updated with more build instructions?



I actually got fairly far with help from Jim Park, but the build process reached the point where all of the header files couldn't be found unless I modified all of the include statements to have an absolute path to the location of the header file. That seemed very wrong, at which point I figured it was a good time to ask for help.

Regards,

~Dave
Joost Verburg#
SCons is probably trying to use MSVC 2005, which is the most recent version supported. Do you also have the Windows SDK installed?
jimpark#
Also, installing MSVS 2008 causes Scons to find it instead of MSVS 2005. This is a problem because Scons currently can't handle MSVS 2008. So Dave, when I said my build system was messed up, I was encountering the same problem you were. I had to actually hack Scons to make it find my copy of MSVS 2005 instead of trying to use MSVS 2008. I emailed you a logging build of Unicode NSIS. I hope that works for you.
jimpark#
For those of you trying to build the logging version of NSIS using MSVS 2005, here's the little edit you'll need to do in your \Scons\Config\ms file. Basically, you need to skip the libcp test because from MSVS 2005 on, there is no longer any need to link to the single threaded version of the runtime library. The linker will automatically link it in for you if you need it.

So in around line 43, you'll need to wrap the whole check in a if MSVS_VERSION < 8.0 check:


# For VS 2005 and up, the single threaded version of C runtime
# need not be explicitly linked.
if float(defenv['MSVS_VERSION'].replace('Exp','')) < 8.0:
libcptest = """
#include <fstream>
int main() {
// %s
std:😳fstream header("test", std:😳fstream:😳ut);
return 0;
}
"""

conf.env.PrependENVPath('LIB', Dir('#/.sconf_temp').abspath)
conf.env.Append(CCFLAGS = ['$EXCEPTION_FLAG'])

if not conf.TryLink(libcptest % 'no change', '.cpp'):
import os, shutil

libdirs = defenv['ENV']['LIB'].split(os.pathsep)

for libdir in libdirs:
try:
libcp = r'%s\libcp.lib' % libdir
shutil.copy(libcp, Dir('#/.sconf_temp').abspath)
if conf.TryLink(libcptest % (r'using %s' % libcp), '.cpp'):
defenv.PrependENVPath('LIB', Dir('#/.sconf_temp').abspath)
break
except IOError:
continue
else:
print "*** Couldn't find a good version of libcp.lib"
Exit(2)
Joost Verburg#
When this check fails the problem is usually a compiler detection problem. So I'm afarid you'll just get another error.
jimpark#
I should have made it clear that the case I was trying to fix was building with Vc8 not Vc9. So with Vc8 (MSVS 2005 / 8.0), you can build the special logging build without the single threaded C runtime. Vc9 is still broken as you mentioned. Vc9 stores the header files differently so the Scons folks will have to fix that problem.

If you have installed Vc9 and have Vc8 on your machine, even if you set the environment variables to use MSVS 8.0 you will still have problems because Scons will go look in your registry and discover you have MSVS 9.0, try to use it and fail. You'll have to hack a Scons Python script to make it return MSVS 8.0 not 9.0. If you are interested in that hack, I can send you the file.
DaveMoll#
Jim,

Thank you for the help, the logging build of the unicode version works perfectly with nicely displayed Japanese characters.
kichik#
Which patch exactly are we talking about? TobbeSweden's is a hack to ignore the fact SCons couldn't recognize his VC version and will make multiple installations of VC mess with SCons' selection. jimpark's patch does the same and ignores the fact ofstream can't be properly built.
pabs#
Hmm, OK. So there is no way to make the scons stuff compatible with all of Microsoft's C/C++ compilers?
kichik#
SCons releases a lot of new versions lately. Are you sure the latest 1.1.0 doesn't already support VC9? If it doesn't, the best method would be submitting a patch for scons\SCons\Tool\msvs.py. For NSIS, you can add a temporary tool and add it to the environment if it claims it found VC9.
pabs#
Pasting the below on behalf of Thomas Gaugler, who did the System::Call port to GCC...

I downloaded the NSIS sources (rev. 5767) from the subversion repository. An initial attempt to build with Visual Studio 2005 from "Visual Studio 2005 Command Prompt" resulted in the same problem (Python 2.5, Scons v1.1.0.r3603):


C:\NSIS>"%PROGRAMFILES%\Python25\Scripts\scons" SKIPUTILS="NSIS Menu"
scons: Reading SConscript files ...
Delete("nsis-17-Nov-2008.cvs")
Delete(".instdist")
Delete(".test")
Using Microsoft tools configuration
*** Couldn't find a good version of libcp.lib
The generated config.log had the following content:


file C:\NSIS\SCons\Config\ms,line 37:
Configure(confdir = .sconf_temp)
.sconf_temp\conftest_0.cpp <-
|
|#include <fstream>
|int main() {
| // no change
| std:😳fstream header("test", std:😳fstream:😳ut);
| return 0;
|}
|
cl /Fo.sconf_temp\conftest_0.obj /c .sconf_temp\conftest_0.cpp /nologo /GS- /EHsc /TP /nologo /GS- /EHsc /D_CRT_SECURE_NO_WARNINGS /D_CRT_NONSTDC_NO_WARNINGS
'cl' is not recognized as an internal or external command,
operable program or batch file.
If I invoke the C compiler from the command prompt then the conftest_0.cpp file just builds fine.

A comparison of the environment variables used in the command prompt and Scons revealed that Scons only takes the environment variables stored in the Windows registry.

"The default value of the PATH environment variable on a Windows system comes from the Windows registry value for the command interpreter. If you want to execute any commands--compilers, linkers, etc.--that are not
in these default locations, you need to set the PATH value in the $ENV dictionary in your construction environment."

Source: http://www.scons.org/doc/1.1.0/HTML/...ser/x1673.html
As a consequence the changes to the PATH, INCLUDE, LIB enviroment variables carried out by the "Visual Studio 2005 Prompt" batch script (vsvars32.bat) won't be propagated to Scons execution environment.

The following patch propagates the current values of the
PATH, LIB, INCLUDE enviroment variables to the Scons
execution environment.


--- NSIS.orig/SCons/Config/ms Mon Nov 17 13:16:03 2008
+++ NSIS/SCons/Config/ms Mon Nov 17 12:53:07 2008
@@ -2,6 +2,11 @@

Import('defenv')

+import os
+defenv['ENV']['PATH'] = os.environ.get('PATH')
+defenv['ENV']['LIB'] = os.environ.get('LIB')
+defenv['ENV']['INCLUDE'] = os.environ.get('INCLUDE')
+
### flags

defenv['ENTRY_FLAG'] = lambda x: '/entry:' + x
The above patch allows me to build NSIS with Visual Studio 2005.

It might be a matter of personal preference whether to take the values of the environment variables from the current running command interpreter or the Windows registry. I would give precedence to the current running command interpreter.

Sorry I did not want to register only to post my comment.
Please feel free to post it.
kichik#
That's exactly TobbeSweden's patch which ignores SCons and assumes the user has configured everything properly. It's not the SCons way of things and doesn't assure everything is properly compiled.
Joost Verburg#
Maybe we can provide an option to use the user environment instead of SCons detection?