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
Archive: Building NSIS with vc9
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
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.
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::ofstream header("test", std::ofstream::out);
| 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.
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... ]
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)
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:
http://nsis.svn.sourceforge.net/view...&revision=4796
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?
I added SKIPUTILS="NSIS Menu"
Finished without errors now :)
Can you post the files you have modified so I can put it in SVN?
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
Originally posted by TobbeSwedenBTW, 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.
I added SKIPUTILS="NSIS Menu"
Finished without errors now :)
Originally posted by SheikThen again, its not something most people need to recompile
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...
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. :confused:
SCons still does not support MSVC 2008. You need to add the workaround TobbeSweden posted.
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?
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'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?
http://nsis.sourceforge.net/Building_NSIS_from_SVN
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
SCons is probably trying to use MSVC 2005, which is the most recent version supported. Do you also have the Windows SDK installed?
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.
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::ofstream header("test", std::ofstream::out);
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)
When this check fails the problem is usually a compiler detection problem. So I'm afarid you'll just get another error.
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.
Jim,
Thank you for the help, the logging build of the unicode version works perfectly with nicely displayed Japanese characters.
BUMP!
Perhaps the patches above should be added to SVN?
Does anyone object if I commit them?
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.
Hmm, OK. So there is no way to make the scons stuff compatible with all of Microsoft's C/C++ compilers?
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.
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::ofstream header("test", std::ofstream::out);
| 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.
Quote: 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.
"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
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.
Maybe we can provide an option to use the user environment instead of SCons detection?
We already do.
scons PATH=... TOOLSET=msvc
Scons 1.2.0 does not fix the compilation issues with MSVS 2008 (VC9), unfortunately. However, there is a simple patch you can apply to msvc.py in your Python\Lib\site-packages\scons-1.2.0\Scons\Tool. The URL for the bug report and the patch is here: http://scons.tigris.org/issues/show_bug.cgi?id=2224
One thing we probably should do with Vc9 is add:
#include <shellapi.h>
I should also mention that the above patch only works in the command line where you run vsvars32.bat to set up the environment variables correctly.
shellapi.h added, thanks. But that SCons patch is, again, against SCons spirit and that's why it requires vsvars32.bat. Those paths are surely saved somewhere in the registry or in some XML file.
Well, hopefully they will figure it out on their next release. They're approach still doesn't help you if you have multiple versions of MS Developer Studio installed on your machine. It always assumes that you will want to compile with the latest and that is not true -- for instance that fact that Scons doesn't support Vc9 makes you wish you can tell Scons to just use Vc8. So I think really the best way to get that intent across to Scons is either add a parameter to Scons to tell it which version of which compiler to use, or it reads the needed information through environment variables, assuming that the user knows what he's doing. This whole going into the registry to figure out what's installed and trying to glean the setup information just doesn't work when Microsoft just decides that some of that information will be in some new other mechanism. For every release of MSDEV, Scons will be behind.
You can tell it which version of MSVC to use by passing MSVS_VERSION to the environment.
I'm not sure that it works.
Every compiler I know takes cues from the environment and Microsoft's compiler is no exception. If your cmd.exe environment is setup for Vc9 and then you try to compile it for Vc8, is it guaranteed to work? Or would you have the potential for conflicting header files and libraries?
It just seems to me that Scons' most fragile feature is the gleaning of the environment variables from the registry. Scons is so useful but I think it shoots itself in the foot when it tries to do something that it really ought not. Let the developer set up the usual environment for the compiler. Trust that he knows what he's doing. Have Scons worry about the project settings being correct for that compiler minus what's usually gotten from the environment. Then I would imagine that Scons won't break as often when a compiler vendor comes out with a new version. Each compiler vendor has to support a command line environment that works -- so make use of that environment.
Of course, this is just my two cents.
But it does work :)
It redefines the environment according to the selected version (defaulting to the highest) and ignores anything you define on your on in your cmd.exe. That's what Visual Studio does as well, so there's no reason it shouldn't work.
As for letting the developer setup his environment, I'd rather not. We are not talking about Linux. Most developers I know and certainly most developers I've gotten questions from, don't know much about the environment. I love it that SCons sets it up for them. New versions are bound to come along but ignoring the old versions won't solve anything. An option is something else and still not a perfect solution as the flags might be all wrong.
I will probably be creating a VC9 tool definition for scons soon for another project. If that happens, I'll submit it as a patch to scons after I add it to NSIS.
Building NSIS 2.46: Python v2.65 + Scons 1.3.0 + VS2010 Express + Windows SDK v7.1
1. Download Python Windows installer 2.x from:
http://www.python.org/download/ and install it,
for example into:
C:\Dev\Python26
2. Download latest Scons for Windows from:
http://scons.org/download.php and install it.
3. Download NSIS source from:
http://nsis.sourceforge.net/Download
and unpack all NSIS files, for example, into
C:\Dev\NSIS
4. Open file named ms located at C:\Dev\NSIS\SCons\Config dir.
Comment the following lines and save file:
90: #stub_env.Append(LINKFLAGS = ['/opt:nowin98'])
108: #makensis_env.Append(LINKFLAGS = ['/opt:nowin98'])
119: #plugin_env.Append(LINKFLAGS = ['/opt:nowin98'])
130: #util_env.Append(LINKFLAGS = ['/opt:nowin98'])
152: opts.Add(BoolVariable('MSTOOLKIT', 'Use Microsoft Visual C++ Toolkit', 'no'))
opts.Add(EnumVariable('MSVS_VERSION', 'MS Visual C++ version', os.environ.get('MSVS_VERSION'), allowed_values=('6.0', '7.0', '7.1', '8.0', '8.0Exp', '9.0','9.0Exp', '10.0', '10.0Exp')))
cd C:\Dev\NSIS
scons SKIPUTILS="NSIS Menu" SKIPPLUGINS=all MSVS_VERSION=10.0Exp
Thank you for the detailed build instructions.
I was now able to build NSIS on XP + VS2010 Express + Windows SDK v7.
Please note, that the python version must be 2.6 or greater.