I am trying to build AWS-CPP SDK on Linux and Windows. It has dependency of OpenSSL, zlib, and libucurl. Although these packages are available on Linux, they are not on Windows. How do I specify the locations of these packages' header files and libraries?
I also have more recently versions of these packages on Linux. How do I override the default paths?
There isn't any special requirements for Windows. As you can see from this: http://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/setup.html
Only Linux requires those extra libraries. On Windows, it will use whatever is provided by platform/Visual Studio.
All 3 dependencies are found for Windows - both x32 and x64 bit architectures.
You may also build them from source.
OpenSSL can be found here (and on other sites too):
https://wiki.openssl.org/index.php/Binaries
Zlib is found at :
https://github.com/kiyolee/zlib-win-build
libCurl can be built from source too:
https://curl.se/docs/install.html
Building from source code is necessary, if you want the resulting .LIBs(static) and/or DLLs, to be compatible with your version of Visual C++/Studio(2005-2022).
Related
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
For example,
npm install vscode-textmate
requires dev tools to compile native C code. Since VSC already installed grammars for many languages as well as the node package precompiled for the current platform - is there a way to load the package already on disk along with the preinstalled language grammar?
Please don't do this. It would create an implicit dependency between your extension and VS Code's internal modules, which we don't guarantee will be the expected version or even exist.
See this thread for pointers on native modules in extensions
I am trying to see if you can distribute a MEX file without requiring the end user to install the C++ runtime libraries.
When you use visual 2010 express to create MEXs, Matlab issues this warning :
Warning: Applications/components generated using Microsoft Visual C++
2010 require that the Microsoft Visual Studio 2010 run-time
libraries be available on the computer used for deployment.
To redistribute your applications/components, be sure that the
deployment machine has these run-time libraries.
Is there a compiler that doesn't require to install the run-time libraries on the end machine?
Yes there is: MinGW(-w64) GCC. It only links to the OS library msvcrt.dll (when you link with the -static option), which requires no installation and is part of Windows.
To get Matlab to work with that, you'll need to jump through some hoops. Here is some information. Ignore the Cygwin stuff, and be sure to use a MinGW-w64 toolchain targetting x64 Windows from the link above. Note I haven't personally tested this, but this is your best bet. It's also unsupported by Mathworks, so you are on your own.
As an aside, what's the problem with installing the MSVC++2010 redistributable anyways? There's no effect on licensing, and running MEX code implies having Matlab installed. Installing one more little thing won't be that much trouble IMHO.
I just installed wdk 7600.16385.1(from here) ,
and find windbg is missing even though I've chosen to install all components.
Is it officially removed from wdk now?
If that's the case,why?
WinDbg is shipped as a part of the Windows SDK. Please, check this link: http://msdn.microsoft.com/en-us/windows/hardware/gg463016.aspx. Install latest Windows SDK, and WinDbg can be found in C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows.
Mine was somehow installed in the directory C:\Program Files\Debugging Tools for Windows (x64)
It's contained in my (installed) copy of this exact WDK build (C:\WINDDK\7600.16385.1\Debuggers\windbg.exe). So no idea why it wouldn't be in yours.
Also, to my knowledge WinDbg was moved into the WDKs (and SDKs), with newer versions not being available through other channels, rather than out of them.
I want to create 64 bit apps for (for example) 64 bit Windows 7. I've searched the web and found some help but couldn't get it to work.
Sorry I've taken so long to respond but I have tried to get the packages suggested to work but they're not easy or else I'm doing something wrong.
Anyway I ran across an environment called pellesc. It consists of a development environment around a compiler which traces is roots back to a 32-bit version that was once (according to Wikipedia) used to develop Quake. From what I've seen so far it's very promising and generates good code too!
In spite of what other people are saying, Eclipse actually has very good support for C++, even in Windows: check out the CDT project. It's very mature and well-supported -- it works for C/C++ at least as well as Eclipse JDT works for Java.
As for the compiler itself, VonC is right, MinGW-w64 (but the mingw-w64 project is moving to mingw-w64.org so i suggest to use mingw-w64.org) is the best option. Eclipse CDT has built-in support for MinGW so as long as you install MinGW first, Eclipse should automatically detect it.
This Eclipse MinGW64 tutorial mentions:
update (Nov 9, 2010): recent MinGW-w64 versions come with 'as', 'g++', and 'gcc' commands. This step may be unnecessary in your MinGW build.
Meaning you won't have anymore to update the GCC assembler, C++ compiler, C compiler and C++ linker, with 'x86_64-w64-mingw32-as', 'x86_64-w64-mingw32-g++', 'x86_64-w64-mingw32-gcc', and 'x86_64-w64-mingw32-g++'.
Other great source for w64 development tools:
Native windows x64 software develop with Mingw-w64 on drangon.org
A 64-bit version of GCC for Windows is available at http://tdm-gcc.tdragon.net/download. I can't see why you would want to use Eclipse for C or C++ programming - try the Code::Blocks IDE at http://www.codeblocks.org instead.
Honestly, I use cygwin. Its compatable with unix so you can easily move systems and has tons of functionality that is gcc friendly (autoconf, make, makedepends, ...). To use gcc to compile to 64 bit add the -m64 option. To compile for windows use the -mno-cygwin option. Make sure though that you're using gcc 3 and not 4 (then you'd use the mingw compiler series). Otherwise, its all the same as unix which is really useful.