This question already has answers here:
How to tell scons to use MinGW instead of MSVC
(2 answers)
Closed 7 years ago.
I have a simple SConstruct file with the following code
path = ['C:\\MinGW\\bin']
env = Environment(ENV = {'PATH' : path})
Program(target = 'myprogram', source = ['main.cpp'])
running 'scons' on cmd gives the following error message:
cl /Fomain.obj /c main.cpp /TP /nologo
'cl' is not recognized as an internal or external command,
operable program or batch file.
scons: *** [main.obj] Error 1
scons: building terminated because of errors.
It looks like SCons does not pick my compiler (MinGW). What am I doing wrong?
I'm on Windows 7 64bit.
After setting tools variable in environment you should use env.Program('...') instead of Program('...'). Below is my working SConstruct for mingw:
path = ['C:\\Dev\\MinGW\\x64-4.9.2-posix-seh-rt_v3-rev1\\mingw64\\bin']
temp = 'C:\\Temp'
env = Environment(ENV={'PATH': path, 'TEMP': temp},
tools=['mingw'])
env.Program('solver-tikhonov.cpp')
SCons is trying to build with the default Windows tools, namely cl, which is the visual studio compiler. You need to tell it to use the mingw toolset, as follows:
path = ['C:\\MinGW\\bin']
env = Environment(tools=['mingw'], ENV = {'PATH' : path})
After doing this, if it still cant find the mingw compiler, you can set it as follows:
env.Replace(CC='path/to/mingw/cc/compiler',
CXX='path/to/mingw/c++/compiler')
Related
I've spent a whole day on this now and I can't seem to get the .lib files to build with VS 2017. I followed the V8 docs here:
https://v8.dev/docs/build
Following the instructions does work, but I end up with a V8 command line program in the out directory and .lib that do NOT work with Visual Studio 2017.
fatal error LNK1107: invalid or corrupt file: cannot read at 0x1422A
I executed this to try to get the build files for the libraries only:
gn gen out/lib --args="v8_static_library=true v8_use_snapshot=true v8_use_external_startup_data=false v8_monolithic=true icu_use_data_file=false is_component_build=false is_debug=false"
Then ran this: ninja -C out/lib
And this was the final result:
ninja: Entering directory `out/lib'
[1632/1645] LINK cctest.exe cctest.exe.pdb
FAILED: cctest.exe cctest.exe.pdb
ninja -t msvc -e environment.x64 -- ../../../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo /OUT:./cctest.exe /PDB:./cctest.exe.pdb #./cctest.exe.rsp
lld-link: error: <root>: undefined symbol: mainCRTStartup
[1634/1645] LINK generate-bytecode-expectations.exe generate-bytecode-expectations.exe.pdb
ninja: build stopped: subcommand failed.
I think I'm missing something, but I have no idea at the moment.
Ok, seems my first mistake was changing the prompt to v8\tools\dev\ and working from there. The "normal" steps I found actually only work properly from the root of the source. I ended up with v8\tools\dev\out\x64.release then ninja -C out/x64.release v8 failed because v8 was not accepted in this setup for some reason.
The other thing I did wrong was to edit the args.gn file directly and save it. The CORRECT process is to run gn args out.gn\x64.release so that after you save AND close the editor, it automatically re-generates/updates the files. Most likely changing the file has no effect on its own, and you'll get confused because ninja won't even see the changes.
The linker error about corrupt files is because is_clang is true by default. Setting is_clang=false fixes that error. It just works, I have no idea why; just take it and go ... ;)
The correct way, from the root that worked for me is:
python tools\dev\v8gen.py x64.release
python tools\dev\v8gen.py ia32.release
python tools\dev\v8gen.py x64.debug
python tools\dev\v8gen.py ia32.debug
This will output files that can be compiled in the "v8\out.gn" folder.
Tip: Run "python tools\dev\v8gen.py list" to see a list of possible build configurations.
Next I updated the build arguments:
gn args out.gn\x64.release
Using these:
is_debug = false <-(or true for debug builds)
target_cpu = "x64"
is_component_build = false
v8_static_library = true
use_custom_libcxx = false
use_custom_libcxx_for_host = false
v8_use_external_startup_data = false <-(or true to use the bin startup files)
is_clang = false
And again for the 32-bit version (changing "x64" above to "x86" of course):
gn args out.gn\ia32.release
Then repeated all the above for x64.debug and ia32.debug.
And compiled them:
ninja -C out.gn/x64.debug v8
ninja -C out.gn/ia32.debug v8
ninja -C out.gn/x64.release v8
ninja -C out.gn/ia32.release v8
Visual Studio 2017 now builds and links my project against them again now (was an old project I resurrected).
Note: Linking against debug versions of V8 libraries may give an error that _ITERATOR_DEBUG_LEVEL does not match. To fix this I simply went to the C++ project settings (Confiuration Properties->C/C++->Preprocessor->Preprocesor Definitions) and added ;_ITERATOR_DEBUG_LEVEL=0 so it matches.
I'm following this guide on building V8 but I am hitting some issues on the compilation step. I am running Windows 10 x64. I am trying to compile with options to embed the engine also.
Running the following command:
ninja -C out.gn/x64.release
Gives me this error:
ninja: Entering directory `out.gn/x64.release'
[1/471] LINK mksnapshot.exe mksnapshot.exe.pdb
FAILED: mksnapshot.exe mksnapshot.exe.pdb
C:/Workspace/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb #./mksnapshot.exe.rsp
LINK : fatal error LNK1181: cannot open input file 'comdlg32.lib'
ninja: build stopped: subcommand failed.
Now I believe I have narrowed down the error to looking for the .lib files in the wrong directory. I have (had) multiple versions installed, so there were multiple folders in my Windows Kit install.
Windows Kits/10/Lib/10.0.16299.0
Windows Kits/10/Lib/10.0.15xxx.0
If I dragged and dropped the comdlg32.lib file from 10.0.16299.0 into the 10.0.15xxx.0 directory then the error changed to a LNK1181 error with a different input file. I did this a few times but I was unsure if this was going to cause issues with different versions and there was probably going to be a lot.
I uninstalled the 10.0.15xxx.0 version which left behind the folder I mentioned, so I removed that and after doing so I have started getting the LNK1181 error with a different input file (advapi32.lib I assume the very first file it can't find). This is how I came to the conclusion about the path being incorrect.
So I have tried a few things to change the path (I hoped just uninstalling the old version would fix it) such as:
Uninstalling the old version.
Going through registry entries to see if I can find an install path or something using that path, which I didn't. I did notice that there was still installation and data in the registry for the 10.0.15xxx.0 install, I might try deleting that from the registry directly as a last resort?
I have tried to explicitly set the path by setting <TargetUniversalCRTVersion>10.0.16299.0</TargetUniversalCRTVersion> in this file: C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\uCRT.props
I have never used Ninja before so I tried looking for a way to set some kind of lib-path in the command but couldn't really find anything.
I looked through the python scripts being executed to try and locate something to do with the libs path but couldn't see anything.
I would be grateful for any help and suggestions. Thanks.
You can try to compile v8 using Visual Studio as explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#using-the-visual-studio-ide
By running the following commands:
$ gn gen --ide=vs out.gn/x64.release
$ cd out.gn/x64.release
$ msbuild all.sln
You can see a full example here: https://github.com/phpv8/v8js/issues/272#issuecomment-262848754
Apparently this method is not officially supported anymore, but I had the same problem as you have and this solved the issue for me.
Note that after this I had another issue, the unit tests failed to be compiled due to a linking error, but I had the necessary libraries to use v8. So there may be deeper problem that is causing all of this that I'm missing.
Edit:
Also, you could try to set the following parameters with gn args:
visual_studio_path = "..."
visual_studio_version = "2017"
wdk_path = "..."
windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
To set those parameters, do:
gn args out.gn/x64.release
This will open a text editor where you can write the extra parameters you are interested in.
To see the full list of parameters you can specify:
gn args --list out.gn/x64.release
I was following this guide https://medium.com/dailyjs/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4 and also ran into the error
LINK1181: cannot open input file 'advapi32.lib'
I'm pretty sure it was because I had the wrong versions of the Windows 10 SDK. Similar to you I had versions:
Windows Kits/10/Lib/10.0.10240.0
Windows Kits/10/Lib/10.0.16299.0
But according to https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows (Which I think is relevant) you need version 10.0.15063.0
After installing version 10.0.15063.0 (with the visual studio installer) to
Windows Kits/10/Lib/10.0.15063.0
I was able to continue with the build.
I am using Windows 7 x32 and have already installed, sublime text 2, MinGW, also set PATH for minGW in system variables, but it still does not work.
I try to build it get [Finished in 0.8s] and then I try run, get this:
[Error 2] The system cannot find the file specified
[cmd: [u'bash', u'-c', u"g++ 'C:\\Users\\air\\Desktop\\test.cpp' -o 'C:\\Users\\air\\Desktop/cc' && 'C:\\Users\\air\\Desktop/test'"]]
[dir: C:\Users\air\Desktop]
[path: C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\Program Files\MySQL\MySQL Server 5.5\lib;D:\QtSDK\Desktop\Qt\4.7.4\mingw\bin;D:\QtSDK\Desktop\Qt\4.8.1\mingw\bin;D:\Program Files\CodeBlocks\MinGW\bin]
[Finished]
It seems that because linux uses "/", but windows uses "\" in the file path. I try to change the "C++.sublime-build", but failed. I really don't know how to fix it, Can anybody help me?
I had the same problem and the answer came simple as 42: since bash needs to be run in cmd command, it must be in the path variable. In my case, bash was contained in MSYS (which can be installed optionally with MinGW), I added C:\MinGW\msys\1.0\bin to path, restarted Sublime Text and now run command is working.
Edit 2 -
I don't have the application file qmake in the /bin folder and this is the error I am getting.
Path environment variable : C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4\bin\
Command Prompt - visual studio 2005
Source folder - C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4
Steps -
Downloaded src
Extracted the files to folder – qt-everywhere-opensource-src-4.7.4(C:\development\referencebuilds\qt\4.7.4)
configure.exe -opensource -fast -no-accessibility -no-qt3support -no-multimedia -no-audio-backend -no-phonon -no-phonon-backend -no-webkit -no-scripttools -platform win32-msvc2005 -D “_BIND_TO_CURRENT_VCLIBS_VERSION=1”
4.nmake
The error I get is
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7
.4\bin\qmake C:/development/referencebuilds/qt/4.7.4/qt-everywhere-opensource-sr
c-4.7.4/\projects.pro -o Makefile -spec win32-msvc2005
'C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4\bin\
qmake' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\development\referencebuilds\qt\4.7.4\qt-everywher
e-opensource-src-4.7.4\bin\qmake' : return code '0x1'
Stop.
I know I dont have the app files for qmake and many other appfiles in my \bin folder. How do I get them?
Edit 1
Well, after trying out all the answers, the situation still remains the same. I think i should add more details to what I am doing.
I am copying bin files(.dll , Appplication, Application Extension, Incremental Linker File, Program Debug Database, ) from another machine and the version of Qt was 4.7.2
My questions are -
1. Do you see that as the cause for all the issues here? If yes, how do I get all the above files? If I just congigure as above and then run nmake I get
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
C:\development\referencebuilds\qt\4.7.4\bin\qmake
C:/development/referen cebuilds/qt/4.7.4/\projects.pro -o Makefile
-spec win32-msvc2008
'C:\development\referencebuilds\qt\4.7.4\bin\qmake' is not recognized
as an inte rnal or external command, operable program or batch file.
NMAKE : fatal error U1077:
'C:\development\referencebuilds\qt\4.7.4\bin\qmake' : return code
'0x1' Stop.
1, Downloaded the source file named
qt-everywhere-opensource-4.7.4 and saved it in folder c:\development\referencebuilds\qt\4.7.4\
2, uncompressed the zip file and the files extracted into folder
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4
3, Copied back all files from the folder
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4 to c:\development\referencebuilds\qt\4.7.4\
4, ran
configure.exe -opensource -fast -no-acce ssibility -no-qt3support
-no-multimedia -no-audio-backend -no-phonon -no-phonon- backend
-no-webkit -no-scripttools -platform win32-msvc2008 -D
"_BIND_TO_CURRENT
_VCLIBS_VERSION=1"
5, nmake and now I get the following errors.
C:\development\referencebuilds\qt\4.7.4\bin\qmake
C:/development/referen cebuilds/qt/4.7.4/\projects.pro -o Makefile
-spec win32-msvc2008 Could not find mkspecs for your
QMAKESPEC(win32-msvc2008) after trying:
C:\Qt\4.7.2\mkspecs Error processing project file:
C:/development/referencebuilds/qt/4.7.4//projects .pro NMAKE : fatal
error U1077: 'C:\development\referencebuilds\qt\4.7.4\bin\qmake.EX E'
: return code '0x3' Stop.
I have no clue as to why it is refering to C:\Qt\4.7.2\mkspecs . How do I get over this error? what is exactly happening. How do I prevent such issues in future?
Your install directory is:
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4
Let's call it $(QTDIR). Now:
Extend your PATH variable to include $(QTDIR)\bin
Specify the QMAKESPEC environment variable to be win32-msvc2005
Open a Visual Studio command prompt to get the Visual Studio environment variables
Run configure
Run nmake
This procedure usually gets the Qt build to work for me.
Make sure that you don't have any existing QT directories in your path before you call configure and nmake.
It looks like you have a previous version of Qt installed. "C:\Qt\4.7.2\". And it would seem you have it setup in your system variables. Look for a variable called QTDIR in your system environment variables. Which is why you are getting an error, basically your 4.7.2 Qt is trying to build the new version.
Two options:
Un-install your old Qt via add/remove software in the control panel.
or
Remove your QTDIR system variable for the time being (will require a re-login) so that when you try to build from source it will use the correct binaries from the source folder.
Then just follow this guide:
http://en.wikibooks.org/wiki/Opticks_Developer_Guide/Getting_Started/Building_Qt_From_Source
First off I should forewarn you that I am a new grad(and EE at that), and not terribly familiar a build process more advanced than my hello world programs.
My issue is: We are attempting to use SCons ton build our project at work. Our compiler is called 'i686-pc-elf-gcc' and uses posix style command line arguments. But whenever I try and use scons it forces Windows arguments, so instead of:
i686-pc-elf-gcc -o hello.o -c hello.cpp
I get
i686-pc-elf-gcc /Fohello.obj /c hello.cpp /TP /nologo
Which our compiler doesn't like.
Here is what my SConscript file looks like
import os
path = ['c:\\compiler\GCC\i686\bin',
'../../build/include']
env = Environment(ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
env.Replace(CC = "i686-pc-elf-gcc")
env['platform'] = 'posix'
env.Program('hello.cpp')
The environment is in a DOS prompt with cygwin installed. I was hoping setting the platform to posix was all that was needed, but I have been beating my head against the wall with no results.
Looks like the default SCons compiler detection is picking up the Microsoft compiler suite. Instead of:
env = Environment(ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
maybe try:
env = Environment(tools = ['gcc', 'g++', 'gnulink'],
ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
This way it will use the gcc toolset instead of the msvc one. If you only overwrite CC then all the flags are still MSVC style, while the compiler is really GNU. So the full SConstruct would be:
import os
path = [r'c:\compiler\GCC\i686\bin', '../../build/include']
env = Environment(tools = ['gcc', 'g++', 'gnulink'],
ENV = {'PATH' : path,'TEMP' : os.environ['TEMP']})
env.Replace(CC = "i686-pc-elf-gcc")
env.Program('hello.cpp')