I use HaxeDevelop 5.2 and Haxe 3.4.2. I tried to build simple Hello world app in HaxeDevelop. But failed.
Here is the log:
Running process: C:\Program Files (x86)\HaxeDevelop\Tools\fdbuild\fdbuild.exe "E:\temp\New Project14\New Project14.hxproj" -ipc 7de8e6ea-dcd6-4496-acea-c62337a09d79 -version "3.4.2" -compiler "C:\HaxeToolkit\haxe" -notrace -library "C:\Program Files (x86)\HaxeDevelop\Library"
Building New Project14
haxe -cp src -cpp "E:/temp/New Project14/bin" -main Main
Unix.Unix_error(21, "open_proc", "haxelib path hxcpp")
Build halted with errors (haxe.exe).
Done(1).
What is the possible reason for this error? When I used the build command directly in the cmd.exe, it didn't fail. I've asked about this issue on github, but nobody has given any answer. FlashDevelop also failed.
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 am trying to compile an existing qt application's code using mingw compiler.
During compilation I am getting an error "*** internal error: unable to open jobserver semaphore '3,4': (Error 2: The system cannot find the file specified. ). Stop".
My current project is a makefile based project. Here I have one make file (parent.mk) that compiles all primary modules and then
parent.mk
compilation steps
.
.
.
make $QT_CODE_DIR
Here in this QT code directory I have another makefile (child.mk) which has following content:
child.mk
cd "qtcode_compilation_out_dir"
qmake.exe "product.pro" -r -spec win32-g++
CONFIG+=release
mingw32-make -w
If I try to run the make command manually for QT code then it works fine.
#Alexander: Thanks for the suggestion.
Please suggest if anyone has any idea about it.
Thanks.
Finally, I found out the exact reason of the problem and solution as well.
Reason for failure:
The compilation command that I am using is "make" which is been aliased to "make -j2"and along with "mingw32-make -w" it was producing the error because mingw32-make is an obsolete make command and it doesn't support multi threaded compilation.
Solution:
I just replaced the mingw32-make with make.
So here's a quick (and probably inane) question from someone new to CMake and Qt.
I'm currently using Qt Creator, alongside of CMake, to create some project. I have 2 C++ files that I have to remove that are no longer used anywhere within the codebase. I have removed them from the project, the CMakeLists.txt file, nuked the build and qt_build directories, and proceeded to try to rebuild. However, I seem to be getting an warning when running qmake which looks like this...
15:03:03: Running steps for project Traveler...
15:03:03: Starting: "C:\Qt\5.9.2\msvc2017_64\bin\qmake.exe" C:\Users\someone\Traveler\Traveler.pro -spec win32-msvc "CONFIG+=debug" "CONFIG+=qml_debug"**
Info: creating stash file C:\...\build-traveler-Desktop_Qt_5_9_2_MSVC2017_64bit-Debug\.qmake.stash
WARNING: Failure to find: src\XX_Exceptions.cpp
WARNING: Failure to find: include\XX_Exceptions.hpp
WARNING: Failure to find: src\XX_Exceptions.cpp
WARNING: Failure to find: include\XX_Exceptions.hpp
15:03:07: The process "C:\Qt\5.9.2\msvc2017_64\bin\qmake.exe" exited normally.
15:03:07: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" qmake_all
It seems as if qmake exits without error, but I really don't like seeing these compiler warnings (especially duplicated, so its showing up in two places).
Then, when I proceed to try to build...
15:16:27: Running steps for project Traveler...
15:16:27: Configuration unchanged, skipping qmake step.
15:16:27: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe"
C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Debug
Error: dependent 'src\XX_Exceptions.cpp' does not exist.
jom: C:\Users\someone\build-Traveler-Desktop_Qt_5_9_2_MSVC2017_64bit-Debug\Makefile [debug] Error 2
15:16:28: The process "C:\Qt\Tools\QtCreator\bin\jom.exe" exited with code 2.
Error while building/deploying project Traveler (kit: Desktop Qt 5.9.2 MSVC2017 64bit)
The kit Desktop Qt 5.9.2 MSVC2017 64bit has configuration issues which might be the root cause for this problem.
When executing step "Make"
Question :: Is there any location where the specific files in the project are referenced besides the CMakeLists after I nuke the build directories?
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'm using Xming to connect to a Linux (enterprise edition) server on which I'm trying to debug a C++ project in Eclipse Galileo. The following errors occurred:
Reading symbols from ../workspace/myfile ..(no debugging symbols found) ... done.
.gdbinit : No such file or directory
Setting environment variable "LS_COLORS " to null value
(.gdbinit is on the server (in root), my account has rights)
If i try to run gmake on the same file from the terminal I get the following error :
gmake ** No rule to make target /workspace/myfile' . Stop.
//I have exported the path (including the library path), and gmake exists.
My project has 3 subprojects (proj1 , proj2 and proj 3). In order to debug proj3 I have to build projs 1 and 2 . I created make targets for projects 1 and 2, and I obtained .so files for which i made softlinks to corresponding files in my_project/libs folder.
My Eclipse debug configuration is as follows (tab order):
Main
Project: My Project
Build Configuration: UseActive
C++ Application: path to my project/myproject
Environment: path to libs on server (my user rights)
Debugger
Debugger: gdb/mi
(Checked) Stop startup at main
GDB debugger: gdb
GDB command line .gdbinit
GDB command set: standard
Protocol mi
Project Properties:
Builders CDT Builder
Scanner Configuration Builder
C/C++ Build
Build command gmake -k
Behaviour
build incremental build : all ( sometimes i get the error no rule for make all)
Clean: clean
Discovery options:
(Checked) Automatic discovery path
(checked) Report path detection problems
Discovery profile GCC per project
(checked ) Enable build output
Compile invocation comand gcc
Toolchain
No toolchain
Correct builder GNU make builder
This Eclipse debug configuration works on another account (on the same server using the same Eclipse). The gdbinit and gmake files are on the server and work, I'm not supposed to update the versions (this was one solution I found online).
Has anyone seen this error before? Does anyone have a clue what I'm doing wrong?