I have followed same step mentioned in this question. Few extra flag I have set get propriety FFMPEG codec. Its failing every time, with following logs.
[233/19712] ACTION Copying D3D Compiler DLL...
FAILED: F:\Chrome\depot_tools\python276_bin\python.exe gyp-win-tool action-wrapper environment.x86 copy_compiler_dll_target_copy_dll_a30e198148542d4bce19a5c818c6884f..rsp ..\..\third_party\angle\src
[233/19712] CC obj\third_party\icu\source\stubdata\icuuc.stubdata.obj
ninja: build stopped: subcommand failed.
For FFMPEG using following set command:
set GYP_DEFINES=branding=Chromium buildtype=Official component=shared_library disable_nacl=1 enable_automation=0 enable_captive_portal_detection=0 enable_google_now=0 enable_hidpi=0 fastbuild=1 ffmpeg_branding=Chrome incremental_chrome_dll=0 proprietary_codecs=1 remoting=0
My System Information Details:
Windows 10 64 Bit 8 GB RAM. Trail Version of Visual Studio 2015
Installed, but now it is expired. Now I have installed Community
Version 2013 update 4.
Does it effect both version effect the execution? Checked in path, its using Window Kit 8.1. What other part should I check for successful execution?
You need to install Win10 SDK. That did it for me.
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=13945#p29872
LE: However, later on in the build you may find all sorts of not found headers and/or other compile errors. This is most likely due to installing Win 10 SDK after having first fired the build\gyp_chromium.py command and realizing that it had not worked. What you need to do in order to move on is delete all the precompiled headers generated in your target output (eg. out\Debug) and then rerun the build\gyp_chromium.py and ninja -C ... commands.
I have picked this up from Daniel Bratell's answer at https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/PacUmAmrWrk
LLE: If still having issues delete the out folder altogether and rerun gclient runhooks; then the ninja -C out\Debug command
Related
I've been working with AWS lambdas for a few months. I was working with a lambda and it was fine at the end of the day. I came back to work on it the next day, and I can't get Visual Studio to even start the application using the Mock Lambda Test Tool.
I ended up creating an empty lambda that just returns the input (the standard project code that AWS gives you as a template) and that won't even run. I hit the play button to star the Mock Lambda Test Tool, it looks like it will run for a couple seconds, then it closes down. The command window does not even pop up.
This is the code from the template project.
public string FunctionHandler(string input, ILambdaContext context)
{
return input?.ToUpper();
}
This is all I get in the output window of VS:
The target process exited without raising a CoreCLR started event.
Ensure that the target process is configured to use .NET Core. This
may be expected if the target process did not run on .NET Core. The
program '[16700] dotnet-lambda-test-tool-2.1.exe: Program Trace' has
exited with code 0 (0x0). The program '[16700]
dotnet-lambda-test-tool-2.1.exe' has exited with code -2147450726
(0x8000809a).
I have tried re-installing the AWS toolkit, and also tried re-installing Visual Studio. This is an issue with VS 2017 and VS 2019. I just installed 2019 to see if that would fix the issue. Any help would be appreciated.
I came to this question having the very same issue. After installing AWS Toolkit I found that the lambda test tool was not installed and therefore I got the same error just as the OP. The only difference is that I was targeting .Net Core 3.1 and therefore I needed amazon.lambda.testool-3.1. However this answer should work for both scenarios.
Unfortunately I did not have the same luck as the OP of having a nice co-worker that could give me the files I needed. So, if this is also your case please continue reading.
In the official project site, which can be found here, there are the instructions to install the tools. It also says that installing the latest version of AWS Toolkit should be enough to have the tools installed (it was not in my case and probably in yours).
It says that in order to install the tools you should run the following commands:
dotnet tool install -g Amazon.Lambda.TestTool-3.1
or
dotnet tool install -g Amazon.Lambda.TestTool-2.1
depending on which tool you need.
However, running these commands fails with the following message:
The tool package could not be restored.
Tool 'amazon.lambda.testtool-2.1' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
And since the project is still in preview I just had to find the latest stable version in order to specify it in the command. For .net core 3.1 here is the nuget site, there I found version 0.10 to be the latest, so the command should look like:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
I have faced the same issue and when i tried to install dotnet-lambda-test-tool-3.1.exe using command prompt I got this issue:
Failed to create shell shim for tool 'amazon.lambda.testtool-3.1': Command 'dotnet-lambda-test-tool-3.1' conflicts with an existing command from another tool.
Tool 'amazon.lambda.testtool-3.1' failed to install.
And I did the following to fix issue
Deleted the dotnet-lamda-test-tool-3.1.exe from the installed folder (C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-3.1.exe)
Run dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1 on cmd.
I have faced the same issue and got errors like "dotnet-lamda-test-tool-2.1.exe has exited with code.."
I did the following to fix the issue
Removed the dotnet-lamda-test-tool-2.1.exe from the installed folder
(C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-2.1.exe)
Removed the [amazon.lambda.testtool-2.1] folder as well
(C:\Users%USERNAME%.dotnet\tools\tools.store\amazon.lambda.testtool-2.1)
Installed dotnet tool from Developer command prompt using the command
[install -g Amazon.Lambda.TestTool-2.1]
Run the project. It is working
I have seen this issue many time on my system with dotnet-lambda-test-tool-6.0. Only one fix work for me
Remove dotnet-lambda-test-tool-6.0.exe from C:\Users\username.dotnet\tools
Open Command prompt from C:\Users\username.dotnet\tools
run command dotnet tool install -g Amazon.Lambda.TestTool-6.0
For anyone else that hits this same issue, it had to do with the the AWS toolkit install. I did not modify it, but somehow it was no longer working. I tried un-installing and re-installing, but it was still having issues running it. A co-worker sent me the exe and subdirectory that was setup on his machine under C:\Users\%user%.dotnet\tools. The exe is located in this directory, and there is another folder under .store for amazon.lambda.testtool-2.1. That directory had different folders and files than what I was able to install. So I copied in what he had and it worked. There might be a profile file associated to the tools install that points to these folders and files that might need to be modified. Since I was able to fix it with this, I didnt look any further into that.
I had the same issue with my .NET 6.0 lambda project. I installed the tool by executing dotnet tool install --global Amazon.Lambda.TestTool-6.0 --version 0.12.6 as suggested on https://www.nuget.org/packages/Amazon.Lambda.TestTool-6.0
Just ensure it is installed at %USERPROFILE%\.dotnet\tools\dotnet-lambda-test-tool-6.0.exe
I got the same issue with VS2019 with lambda design in 3.1 version and in Output window getting error
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
Then checked the folder having multiple version of lambda-test-tool in path
C:\Users{username}.dotnet\tools
I removed all the lambda-test-tool and installed the required tool only with version 3.1 by command in developer command prompt:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
Then I can able to debug the lambda
so I am trying to compile openjdk8 from sources, but I am stuck at missing files problem in the end of compilation process...
Here is the software that I use:
Windows 7 SP1 x64
Windows SDK for Windows 7.1
Microsoft .NET Framework 4
Visual Studio 2010 Express Edition
GNU make 3.82 (compiled by myself)
Freetype 2.3 (compiled by myself)
Oracle JDK 1.7 update 71
Direct X 9.0 (August 2009)
Cygwin
Here are the manuals which I was reading from:
Official README
Royvanrijn's build guide
Some other build guide
Build guide using MSYS
With all these guides I am able to let it compile, however during the Building Images - step , I get an error that some files are missing ( and they are indeed missing ) , which makes me think that something has gone wrong during the build...
There are several points where I afraid I might be doing something wrong...
Cygwin
Right now I use cygwin version 2.8. The openjdk configure script requires cygwin version >1.7 but fails to recognize that 2.8 is greater than 1.7 and throws me an error, so i've tweaked the script (made build work like 2 months ago)...
./configure
My configure command looks as follows:
./configure --disable-ccache --with-freetype=/cygdrive/c/freetype
Maybe I need more arguments here to make it work ( note that i've copied self compiled make executable to cygwin bin folder, so that i dont need to provide its location )
Visual Studio C++ 2010 Express
I would rather try Professional Trial version, but it cannot be found anywhere anymore... (except torrents...) I have a strong feeling that Express version is not suitable for openjdk build. I also get that error with missing ammintrin.h file, but it is easily resolved by creating the empty header file in the include folder of Visual Studio installation.
My basic procedure of building is:
Install all the software above
hg clone http://hg.openjdk.java.net/jdk8/jdk8
./get_source.sh
./configure --disable-ccache --with-freetype=/cygdrive/c/freetype`
make clean images
However, here how it ends :
Does anyone have any clue of how to solve this?
I found the proper fix: using the Cygwin installer, downgrade Grep to 2.27, which properly ignores CRLF line endings.
Run the Cygwin setup (e.g. setup-x86_64.exe)
Advance through the setup wizard until you get to the package selection
Choose "Full" from the View drop-down menu
Type "grep" into the search field
Click the icon in the New column until it shows a 2.x version (2.27 as of this writing)
Click Next and then Finish.
I found myself in the same position as you, except in my case I need OpenJDK build to be repeatable, so "run make repeatedly until it finishes" wasn't an acceptable solution.
Through some experimenting, I found the root cause:
grep was failing because the file being processed had Windows line endings (CRLF)
The Windows line endings were due to the fact that the file is generated by a Java app (fixpaths) which emits platform-native line endings
Identifying fixpaths led me to an old OpenJDK e-mail thread, which reported that some users were having the same problem and fixed it by downgrading.
This gave me the idea to try downgrading grep. I did so, and it worked.
So, after couple of days at this task my only approach was to ignore the errors with the missing files and continue extracting files... This resulted in still working jdk image, which i currently use. My guess is that the errors come frome Oracle boot jdk. Since i am compiling an openjdk, it cannot find oracleJDK files in its headers and thus produces errors.
So, if anyone also gets same errors a me, try to ignore the missing files error and continue the images build.
During linking I get this message:
LINK : fatal error LNK1101: incorrect MSPDB120.DLL version; recheck installation of this product
I have seen solutions for similar errors on previous versions of VC2013 but those did not work for me. Those include:
running C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat
adding %VS120COMNTOOLS% environment variable to the PATH environment variable
Reinstall or Repair the installation of MSVC2013 (NOT RECOMMENDED)
The first time I got this error I went ahead with a full reinstall of VC2013. I chose to take this rout because I thought maybe I had screwed up the install by installing older versions of VC after installing VC2013. Although reinstalling worked the first time, I can't recommend doing this. The MS installer seems rather broken and hung up on me on repeated attempts, resulting in the loss of 5+ hours of my life.
What are some other solutions to this problem if the first 2 options do not work?
Open Task Manager.
Check for the currently running processes mspdbsrv.exe and kill it if it is running and try again. I don't know why this works, but I have to do it every once in a while. The process comes back each time you compile and it seems random whether or not it gets stuck on this step.
Alternatively, if you do not need debug information generated, you can skip this process altogether by setting:
Project Properties -> Linker -> Debugging -> Generate Debug Info ->
No
I just had this happen. In my case, I had a statically-linked shared 'helper' lib that was compiled with the cl.exe CRT flags "-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE", whereas my target app that linked in this helper lib did not have these set. Once I added these flags to the app's cl.exe flags, all was good.
I get this error message when another compile (jenkins) is still running in the background.
Waiting for it to finish, and retry fixes the error.
I am trying to build and link OpenSSL on Windows 8 and I've found it really daunting. I should mention that I am aware of following posts
OpenSSL Windows x64 Compilation error
How do you compile OpenSSL for x64?
Building OpenSSL VC++ Static 64bit Libs
but none of them addressed what I do really need to know. Therefore I decided to share my experience with you guys as a new post!
First, I can successfully build and link OpenSSL on a Win32 OS and it perfectly works. I know that Windows 8 comes with WOW64. “WOW64 is an x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows”, though when I run my app that is built on windows 7 32-bit, I receive an error “The program can’t start because libeay32.dll is missing from your computer…” while “libeay32.dll” is apparently there and not missing.
In order to avoid registry missing stuffs, I tried to build OpenSSL in 32bit mode on Windows 8. The build was successfully done and the app linked correctly with no error. Again when I run the app I received the same error message.
And then I tried to build it in 64bit mode based on the following steps;
set PATH=%PATH%;c:\perl\bin;c:\nasm;
call "c:\visual studio\2012\vc\vcvarsall.bat" x64
perl Configure VC-WIN64A no-shared no-idea
call ms\do_win64a
copy ms\libeay32.def ms\libeay64.def /Y
copy ms\ssleay32.def ms\ssleay64.def /Y
ssed -e s/out32/out64/g ms\ntdll.mak | ssed … > ms\ntdll-64.mak
ssed -e s/out32/out64/g ms\nt.mak | ssed … > ms\nt-64.mak
nmake -f ms\ntdll-64.mak
nmake -f ms\ntdll-64.mak test
nmake -f ms\ntdll-64.mak install
In this case, I received a lot of warnings mostly on “data conversion and possibility of data loss” during build but it was built and while “test” failed “install” generated outputs.
Now when I try to build my solution in Visual Studio using new “libeay64.lib and ssleay64.lib” I receive almost thousands of errors saying “unresolved external symbol”
So if possible please answer following questions;
Why I cannot run my 32bit app on Windows 8 (64bit)?
Why correctly built OpenSSL (32bit mode) on Windows 8, still
encounters same error?
In OpenSSL build (64bit mode), am I making something wrong?
I am using OpenSSL ver 1.0.1e, Visual Studio 2012 and nasm 2.10.07
Thanks
I am partially answering your question:
You can run 32-bit under 64-bit in WOW64.
For OpenSSL under 64-bit, there is a compiler option /WX under visual studio which means treat warnings as an error. Remove that compiler option from the makefile. You will get lots of warnings. But OpenSSL will get compiled.
Since, most of the modules are not compiled and their object file is not generated, that is why you are getting linker error. Please let me know if it solves your problem.
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b