Windows: How to build X264.lib instead of .dll

Windows: How to build X264.lib instead of .dll - c

I downloaded the X264 source and installed mingw.
Step 1:
Executed this in the MINGW bash:
./configure --disable-cli --enable-shared --enable-win32thread -
-extra-ldflags=-Wl,--output-def=libx264.def
and then 'make'
Step 2:
Renamed the libx264-142.dll to libx264.dll and Opened up VS2012 Command Prompt and executed this:
LIB /DEF:libx264.def
which gave me libx264.lib and object libx264.exp
Step 3:
Included the lib file in a VS2012 project which uses the X264 API.
Problem:
When I start the project I get the following error message:
"The program can't start because libx264.dll is missing from your computer"
Question:
Why is it looking for the dll when I'm linking the static library in?
How do I resolve this? I would like to build a static X264 library which I can link in with my project.
EDIT:
I just had to put the dll in the same directory as the project executable.
However - My question still stands: How do I build a static x264 library? So I don't need the dll?

After the latest update of x264 you can build static library usable by MSVS project. For such library compilation you will need:
MSYS and MSVS 2013 Update 2 (express version [for Windows Desktop] would also work if you install Update 2)
run "VS2013 x86 Native Tools Command Prompt" or "VS2013 x64 Native Tools Command Prompt" depending what version (32 or 64-bit) you want to build
change dir to x264 path and run MSYS shell (sh)
from shell run "CC=cl ./configure --disable-cli --enable-static" for x264 configuring
run "make" which should build libx264.lib usable from MSVS
P.S. MSVS builds would be a little bit slower than one build by MinGW

Matthew Oliver has a GIT repository of a patched x264 source tree (https://github.com/ShiftMediaProject/x264) that compiles natively in VS2013 update 2 and later. It requires installing a YASM version for VS.
It worked pretty much straight out of the box for me, though I did have to change the VSYASM parameter "-f Win32" to "-f win32" for a 32bit build
Take a look here: http://siliconandlithium.blogspot.no/2014/03/building-x264-on-windows-with-visual.html

Static lib is not possible in windows as per my knowledge.

Related

compile putty 0.78 for windows

in the new version of putty there is no Makefile.vc or project file for visual studio. How can I compile putty under visual studio 2019? can someone help me?
link to zipped source
I tried to open the windows folder in visual studio with the following error:
Severity Code Description Project File Line Suppression State
Error CMake Error at C:\Usersuser\Downloads\Compressed\putty-src\windows\CMakeLists.txt:3 (add_sources_from_current_dir):
Unknown CMake command "add_sources_from_current_dir". C:\Users\user\Downloads\Compressed\putty-src\windows\CMakeLists.txt 3

You don't need to open Visual Studio or any IDE to compile the executables.
Download cmake and make sure Visual C compiler is installed.
Unzip the .zip file, open a command prompt where the readme and CMakeLists.txt reside
Then, as the readme states:
run these commands in the source directory:
cmake .
cmake --build .
In the Debug directory, you'll find a lot of .exe files.
Then, to install in the simplest way on Linux or Mac:
cmake --build . --target install
I didn't need that part. I suppose that it copies the executables & other files somewhere in the path.
Problem with creating a distro using Microsoft compiler is that the executables then require a lot of Microsoft runtime DLLs. For instance if you deploy the executables on other machines it may not work.
An alternative is to use gcc and make to build the executables.
First:
install a recent gcc for windows
install make
Installing a recent MinGW distribution should do it. Personally I used another gcc distribution so I had to grab make too.
Now, I followed Setting default compiler in CMake, the key part being to enable mingw makefiles: -G "MinGW Makefiles", else cmake ignores your compiler requirements and keeps on using Microsoft compiler.
cmake -DCMAKE_MAKE_PROGRAM=/path/to/make/make.exe -DCMAKE_C_COMPILER=/path/to/gcc/gcc.exe -G "MinGW Makefiles" .
Note that specifying full paths require that / are used. Backslashes conflict with escaping in cmake/make files.
Then
cmake --build .

How do i perform make file in windows

i want to use this library https://github.com/json-c/json-c with my C program in codeblocks(windows) but i dont know how to make makefile/cmake on windows.
I dont know how to do it in this particular example. There is only something like "Config.cmake.in".
Any ideas?

You didn't state what kind of build environment you are using on Windows.
So find below a short description how i built the 32-bit version of json library on Windows 10 using cmake 3.14.3 and Visual Studio 2015. CMake supports several generators for Visual Studio as well as MinGW (see CMake documentation).
Open command window (cmd.exe) change to root directory of json-c library source.
Setup build configuration for 32 bit target in directory "build" using command line "cmake -G "Visual Studio 14 2015" -A Win32 -B build"
Open command window for Visual Studio 2015 x86 environment (link at start menu) and change to build directory created during previous step.
Run "msbuild json-c.sln" to build Debug version of json-c dynamic library
Run "msbuild json-c.sln /p:Configuration=Release" to build Release version of json-c dynamic library
After that you should be able to add the built library to your project.

Statically link libraries into a dynamic library (dll) [duplicate]

I'm working on a C++ application for Windows that uses OpenSSL 1.0.1e library. I'm on Visual Studio 2008.
For portability reasons my application is statically linked against runtime libraries (/MT and /MTd options). And I don't ship runtime libs with my application.
Per the OpenSSL FAQ, the library is by default linked against multithreaded DLL runtime (/MDd) which is obviously incompatible with my scenario. So to make my program work I've added applink.c to my project. On my dev machine and on most test computers the program works fine.
But unfortunately I've located computers where the app doesn't start. Windows displays error:
The application failed to initialize properly (0xc0150002). Click on OK to
terminate the application.
I've opened libeay32.dll in Dependency Walker and I see that MSVCR90.dll is not found. So the trick with applink.c doesn't really work for me.
How do I build OpenSSL with /MT or /MTd option?

Use the nt.mak makefile rather than the ntdll.mak makefile.
As an aside, I have written some scripts around the standard OpenSSL build scripts which make it 'easier' (for me at least) to use OpenSSL on Windows with a mix of both x86 and x64, you can get them from here.

To build 64-bit OpenSSL statically linked (which results in a single .exe file without any DLLs) with Visual Studio 2015, you will need the following prerequisites:
Git for Windows. You can download it at https://git-scm.com/download/win. This guide uses version 2.11.0.3.
Strawberry perl. You can download it at http://strawberryperl.com/ (Warning: ActivePerl is highly not recommended. It will give you strange errors during the process). This guide uses version 5.24.1.1.
NASM assembler, which is available from http://www.nasm.us/. This guide uses version 2.12.03rc1.
You are expected to install all those tools system-wide and add them to your %PATH% environmental variable.
After you got everything we need, just follow this simple steps:
Open VS2015 x64 Native Tools Command Prompt from your Start Menu. You will see command prompt.
Create C:\build directory and issue the following command in the command prompt:
cd c:\build
Download latest zlib & OpenSSL source codes to your build dir by using the following commands:
git clone https://github.com/madler/zlib
git clone https://github.com/openssl/openssl
First we have to build static zlib. To do that first we will need to edit some configuration files:
Navigate to the zlib source folder: cd C:\build\zlib
Edit the win32\Makefile.msc file:
Find the line starting with CFLAGS
Replace -MD with -GL -MT -Zc:wchar_t-
Find the line starting with LDFLAGS
Replace -debug with -opt:icf -dynamicbase -nxcompat -ltcg /nodefaultlib:msvcrt
Build zlib using the following command (should take less than a minute):
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -DNDEBUG -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Copy resulting files to your OpenSSL directory:
xcopy zlib.h C:\build\openssl\
xcopy zconf.h C:\build\openssl\
xcopy zlib.lib C:\build\openssl\
xcopy zlib.pdb C:\build\openssl\
Navigate to OpenSSL source: cd C:\build\openssl\ and configure it to use static zlib & read configuration files (openssl.cnf) from C:\Windows\ directory.
perl Configure VC-WIN64A no-shared zlib no-zlib-dynamic threads --prefix=C:\Windows\
Now make the following edits to the C:\build\openssl\makefile:
Find the line that starts with: CFLAG
Append: /Zc:wchar_t- /GL /Zi
Find the line that starts with: LDFLAGS
Replace /debug with /incremental:no /opt:icf /dynamicbase /nxcompat /ltcg /nodefaultlib:msvcrt
Find the line that starts with: EX_LIBS
Replace ZLIB1 with zlib.lib
Save changes
Build OpenSSL by issuing the nmake command (will take around 15 minutes).
The resulting ~3MB openssl.exe file will be located at C:\build\openssl\apps\ directory. It is fully portable, since all DLLs are included. If you need to use custom configuration file, copy C:\build\openssl\apps\openssl.cnf to your C:\Windows\ directory & edit it to your liking.

The most elegant option I have found for Windows involves using the scripts provided at http://p-nand-q.com/programming/windows/building_openssl_with_visual_studio_2013.html
They provide scripts for VS2010/VS2013/VS2015 for each script version it builds all combinations of x86/x86-64 with runtimes MDd/MD/MTd/MT.
Quoting the instructions:
PREREQUISITES:
The script assumes you are on Windows.
The script assumes you have Visual Studio 2010, 2013 or 2015 installed
in all the usual places. Important: If you have a different
installation folder, your mileage may vary
The script assumes you have downloaded an OpenSSL tarball, like this
one.
The script assumes you have Python (2.7 or 3.x) installed and on your
PATH
The script assumes you have 7-zip installed (doesn't need to be on
your PATH) Choose the script you want to use and edit it. For example,
let's take a look at the top of rebuild_openssl_vs2015.cmd:
T:
set OPENSSL_VERSION=1.0.1p
set SEVENZIP="C:\Program Files\7-Zip\7z.exe"
set VS2015="C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\vcvars32.bat"
set VS2015_AMD64="C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\amd64\vcvars64.bat"
so it is pretty easy to see: you must enter the OpenSSL version
manually, the rest should have sensible defaults...
Note: The script uses the SUBST T:\ drive for building OpenSSL.
I tested and it works, in less than 10 min! KUDOS for the authors of the scripts!!
UPDATE: For the x64 builds to be generated you need to install nasm assembler and have it in the PATH.

If you want precompiled OpenSSL libraries with MT look here: http://www.npcglib.org/~stathis/blog/precompiled-openssl/
You will find a patch for the OpenSSL sources that enables producing libraries with suffixes MT/MD and "d" for debug to make identifying the libraries easier.
What's more, you will also find the actual build script to build all of them at once for many different version of Visual Studio. I build and use them myself to exactly produce binaries that need no DLLs for my projects and you may find them useful.

It appears OpenSSL now links with -MT -Zl (at least when using msvc) meaning it discards default named libraries which are then decided in your final binary. Applications appear to use the static runtime by default.
In other words, no action needs to be taken in order to use it with your binary, just provide whatever flag you want and the OpenSSL library will just work with it. Unfortunate there isn't a lot of concrete documentation on building such an important library.

I solved this problem by manually editing the ntdll.mak file. You only need to change two lines:
in the CFLAG line change /MD with /MT
in the EX_LIBS line append these libraries: libcmt.lib libvcruntime.lib
Save the makefile then run nmake as per OpenSSL instructions.
You can check that the Windows runtime dependencies has been removed with these commands (VS Command Line):
dumpbin /dependents out32dll\libeay32.dll
dumpbin /dependents out32dll\ssleay32.dll

How do I build OpenSSL statically linked against Windows runtime?

I'm working on a C++ application for Windows that uses OpenSSL 1.0.1e library. I'm on Visual Studio 2008.
For portability reasons my application is statically linked against runtime libraries (/MT and /MTd options). And I don't ship runtime libs with my application.
Per the OpenSSL FAQ, the library is by default linked against multithreaded DLL runtime (/MDd) which is obviously incompatible with my scenario. So to make my program work I've added applink.c to my project. On my dev machine and on most test computers the program works fine.
But unfortunately I've located computers where the app doesn't start. Windows displays error:
The application failed to initialize properly (0xc0150002). Click on OK to
terminate the application.
I've opened libeay32.dll in Dependency Walker and I see that MSVCR90.dll is not found. So the trick with applink.c doesn't really work for me.
How do I build OpenSSL with /MT or /MTd option?

Use the nt.mak makefile rather than the ntdll.mak makefile.
As an aside, I have written some scripts around the standard OpenSSL build scripts which make it 'easier' (for me at least) to use OpenSSL on Windows with a mix of both x86 and x64, you can get them from here.

If you want precompiled OpenSSL libraries with MT look here: http://www.npcglib.org/~stathis/blog/precompiled-openssl/
You will find a patch for the OpenSSL sources that enables producing libraries with suffixes MT/MD and "d" for debug to make identifying the libraries easier.
What's more, you will also find the actual build script to build all of them at once for many different version of Visual Studio. I build and use them myself to exactly produce binaries that need no DLLs for my projects and you may find them useful.

It appears OpenSSL now links with -MT -Zl (at least when using msvc) meaning it discards default named libraries which are then decided in your final binary. Applications appear to use the static runtime by default.
In other words, no action needs to be taken in order to use it with your binary, just provide whatever flag you want and the OpenSSL library will just work with it. Unfortunate there isn't a lot of concrete documentation on building such an important library.

I solved this problem by manually editing the ntdll.mak file. You only need to change two lines:
in the CFLAG line change /MD with /MT
in the EX_LIBS line append these libraries: libcmt.lib libvcruntime.lib
Save the makefile then run nmake as per OpenSSL instructions.
You can check that the Windows runtime dependencies has been removed with these commands (VS Command Line):
dumpbin /dependents out32dll\libeay32.dll
dumpbin /dependents out32dll\ssleay32.dll

Cross compile GTK+ application from Linux to Windows?

How can I cross compile my GTK+ app (written in C) from Linux to Windows? Could I just replace the "gcc" command with "mingw32"?

Fedora has a great mingw32 cross-compiler toolchain which comes with lots of precompiled libraries, including GTK+ and gtkmm. For most applications you just need to install the cross-compiler and the cross-compiled GTK+ libraries:
yum install mingw32-gcc mingw32-gtk2
Once everything needed is installed, compiling your application is just the matter of running "mingw32-configure" followed with "make".
More information at the project page https://fedoraproject.org/wiki/MinGW

You can use mingw-cross-env - all you have to do then is to change your CC/CXX environment path to use the i686-mingw32- prefix and export the mingw-cross-env bin dirs (both) to your PATH variable (or if you are using autotool it's even easier) - see the documentation on the homepage.

There is actually a project called MXE that does exactly this.
Pre-build package
You can download my pre-build binaries if you want.
Build from source
You can also build the code from scratch ideally also applying this PR to update to the latest GTK 3.24 version.
MXE has a easy wrapper (x86_64-w64-mingw32.static-cmake) to cross-build your project towards Windows, while using Linux. Allowing to evenly statically build your project into a single .exe file! Of course shared builds (x86_64-w64-mingw32.shared-cmake) are also supported. The example wrapper scripts are meant for CMake based projects.
Before you can build your project with MXE, you need to build the GTK3 from source-code. (There are some Linux packages available, but mostly out-dated). If you are using C++, you can also build gtkmm3. Since you are in place C, you only need to build gtk3.
git clone https://github.com/mxe/mxe.git
Become root user: su
mv mxe /opt/mxe
cd /opt/mxe
Build the MXE project yourself:
For static builds under Windows 64-bit for GTK3 & Gtkmm3:
sudo make gtk3 gtkmm3 -j 16 MXE_TARGETS='x86_64-w64-mingw32.static' MXE_PLUGIN_DIRS='plugins/gcc12'
For shared build to Windows 64-bit (again GTK3 + Gtkmm3):
sudo make gtk3 gtkmm3 -j 16 MXE_TARGETS='x86_64-w64-mingw32.shared' MXE_PLUGIN_DIRS='plugins/gcc12'
More info see the tutorial steps on MXE.cc.
Once you done the cross-compile environment / MXE build. Now you can use the CMake wrapper scripts I mentioned earlier. Those scripts are located in the /opt/mxe/usr/bin/ directory.
The scripts (like x86_64-w64-mingw32.static-cmake) can now be used to compile your project towards Windows, while using the Linux operating system. The build result would be an Windows .exe.
Disclaimer: I personally created this PR for MXE to update GTK to the latest 3.24.x release.