Objective
I am trying to build:
an x264 static library (.lib) with swscale support. I would like to use this library in a Visual Studio project where 24-bit RGB bitmap images are:
Converted from RGB to YUV2
The converted image is sent to the x264 encoder
and the output of the encoder is streamed to a remote IP-endpoint via UDP.
an x264 executable (.exe) with swscale support. I would like to use the executable for the same purpose as described above. In another Visual Studio project, I will start the x264.exe up as a separate process and pipe bitmap data to the x264 process via its stdin and read out the encoded data from the process's stdout.
Problem
I am having some trouble figuring out how to compile with swscale support. I need swscale support for both the executable and the library.
Status
So far I have downloaded the latest x264 source from the x264 website.
I have installed MINGW on my machine and when I run 'configure' and 'make' I get the x264 static library - but without swscale support.
I haven't been able to find a detailed step-by-step guide on how to include swscale in the x264 library. The closest I've come to a description is this discussion:
http://forum.doom9.org/showthread.php?t=165350
So I downloaded libpack from:
http://komisar.gin.by/mingw/index.html
and extracted it to my harddrive:
Then I executed 'make' and 'configure' (again) in my x264 directory:
./configure --extra-cflags="-I/m/somePath/libpack/libpack/libpack/include" --extra-ldflags="-L/m/somePath/libpack/libpack/libpack/lib"
I have the following in the lib and include directory:
When I execute the above 'configure' I get:
platform: X86
system: WINDOWS
cli: yes
libx264: internal
shared: no
static: no
asm: yes
interlaced: yes
avs: avisynth
lavf: no
ffms: no
mp4: lsmash
gpl: yes
thread: win32
opencl: yes
filters: crop select_every
debug: no
gprof: no
strip: no
PIC: no
bit depth: 8
chroma format: all
You can run 'make' or 'make fprofiled' now.
bash.exe"-3.1$
When I execute 'make' I end up with this error:
gcc.exe: error: unrecognized command line option '-fomit-frame-poin'
gcc.exe: fatal error: no input files
compilation terminated.
make: *** [.depend] Error 1
bash.exe"-3.1$
Question
What am I doing wrong??
A couple of things I would point to:
MinGW can sometimes cause compilation issues (because of Windows-based compatibility requirements - I am not saying MinGW is not good). I try to compile on native UNIX system when ever possible.
ffmpeg has built in support for swscale. If you cannot find a way to fix your problem you may want to consider using ffmpeg with x264 support. How to compile here or use a static build.
ffmpeg libswscale source can be obtained here. You could want to download it and compile x264 with a configure pointing at it.
you can always check ./configure --help for more information
1) You can't build "an x264 static library (.lib) with swscale support" because they are separate libraries and should be used together in project not by building one in another. Also you can't build libx264 static library useable by MSVS unless you build with ICL because you will have a lot of problems trying to mix MinGW build libraries (.a) into MSVS projects. I will recommend to use shared library (.dll) in case you want to use libx264 in MSVS project. You can find how to build .lib for libx264.dll using Google.
2) To build x264 executable with swscale support you need to provide x264's configure with path to swscale library and headers which are part of ffmpeg/libav project and build with them.
As for problems while building with komisar's libpack. Your configure command line looks correct but it still didn't configured it with swscale (resize filter is missing from configure output). To find out reason you need to look into config.log file which is created by configure but most likely swscale was outdated (and don't have some API values used by x264) in libpack you used.
As for gcc.exe: error: unrecognized command line option '-fomit-frame-poin' I am dunno from where you get this wrong option because it should be -fomit-frame-pointer but you didn't posted full command line of gcc that resulted in error. May be you specified it somehow yourself (environment CFLAGS) or it is some truncation of command line (too long command line).
Related
I am trying to compile an X11-based program to visualize atomic structures called v_sim on MacOSX Monterey (12.6) on a M1 Apple system. I am compiling the program using a command line environment and there is an option in the configure program to specify Apple's openGL framework "--with-apple-opengl-framework". The configure program stops, however, with the error
configure: error: "No 'GL/glx.h' header file."
How can I specify the location of this header file? There doesn't seem to be an option in the configure command to do so. There also does not seem to be header files in the Framework subdirectories. Any suggestions as to what to try next?
Disclaimer: I'm no software engineer or programmer. I just know enough to get myself in trouble. Please forgive any misused or inaccurate terms.
I'm currently trying to test my HDF5 installation using the in-built Example test scripts. These are organised by CMake and compiled by gcc (MinGW and MinGW-w64). When I go to execute the test script:
ctest -S HDF518_Examples.cmake -C Release -V -O test.log
I'm met with pages and pages of errors, the core of these being:
mingw32-make.exe[2]: *** No rule to make target 'C:/aroot/stage/Library/lib/z.lib', needed by 'bin/h5ex_d_compact.exe'. Stop.
From my hours of trying to fix this on my own, I've been able to work out that z.lib is a library file part of the ZLIB library, ubiquitous these days. I also know that I have at least one copy of this particular file in my Anaconda directory under /Library/lib/.
I have two questions:
1) How can I get CMake or MinGW to recognize where this file is, and hence stop this error? Is there an environment variable I can set, or a config file I can modify?
2) As an aside, where did this path come from? There is no C:/aroot/ directory on my computer. I've also been unable to find any generators for this path in any of the CMake, HDF5, or MinGW files. So why is CMake pointing to this faux-directory?
Any help would be appreciated.
I use ENVIRONMENT PATH in set_tests_properties to specify the dependent external libraries.
set_tests_properties(${Testname} PROPERTIES ENVIRONMENT
PATH=${/your/zlib/location}
WORKING_DIRECTORY "${/your/working/directory}/")
I am interested in attempting to compile, package and flash Embox to an MCU, from either a Windows or Mac machine (cross-compilation), via JTAG, and I have a number of concerns.
Observe what I believe to be the normal way of writing Embox apps and deploying/flashing them to an MCU:
As you can see, in my understanding above:
Embox source code is compiled (via make) into some file (Object file?), <file>.<ext>
At the same time, my app's source code is cross-compiled (somehow) into an Object file (myapp.o) that is compatible with Embox
Some tool combines: (a) the Embox <file>.<ext> produced by make, (b) myapp.o and (c) any other libs I specify. It takes these as inputs and produces a single application image that is ready to be flashed via JTAG
My concerns, also identified in the illustration:
What is the exact name and file extension of the Embox "artifact" produced by running make on Embox source code? Is this artifact different depending on whether you are on Windows or Mac? What tools besides make are necessary to produce this artifact?
What is this magic tool that takes in Object/interim files and produces a single app image? What is the exact name and file extension of this app image?
What tools do I need to cross-compile myapp.c and myapp.h into a myapp.o that is Embox compatible?
I'm one of the Embox developers, who is responsible for build tools.
Basile has given a correct overview of the process as a whole:
the source is compiled into a relocatable embox.o with ld -r,
then linked into embox ELF binary,
... which in turn is additionally transformed into .bin and .srec that are used for flashing quite often.
Binary artifacts go into build/base/bin.
Let me add few details.
First of all, you'll probably won't need to dig into the details of linking your application against Embox. Instead, the proper way is to integrate your app into Mybuild - the Embox build system - and let it handle low-level linkage details for you. So it's worth building vanilla Embox first and see it running on an emulator.
Building and running Embox for ARM
I would suggest you to start with arm/qemu template. This won't fit into your MCU, but if your application doesn't do something unusual, it would be easier to test it on QEMU before porting it to the target MCU. Anyway, this is a good starting point to check that a dev environment is sane and everything builds OK.
Developing on Linux would really make your life easier, like just sudo apt-get install build-essential plus few packages and installing a cross-compiler. However, if you're going to develop on Windows, you may find this guide useful. In addition, you'll need to patch make to make it work on Windows: Issue 504. And here is how to setup QEMU.
The recommended cross-compiler for ARM is the official GNU Tools for ARM.
So basically, here are steps to prepare a Linux dev machine for building and running Embox for ARM:
sudo add-apt-repository -y ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install build-essential gcc-arm-none-eabi u-boot-tools qemu-system
Clone the repository:
git clone https://github.com/embox/embox embox
cd embox
Build arm/qemu:
make confload-arm/qemu
make
confload target initializes a conf/ directory with a predefined template called arm/qemu. conf/ is where a configuration of the target image (Embox + your app) resides.
Run QEMU. There's a handy wrapper for that, that infers the necessary options from the Embox configuration and runs QEMU properly:
sudo ./scripts/qemu/auto_qemu
If everything goes fine, you'll see something like that. Type help to list available commands.
Adding your application as an Embox command
Personally, when trying something new to me I usually "mimic" someone else's approaches to get the first feedback from the application/system. Here, I'd suggest to derive, e.g. an existing cat command, throw everything away from it, effectively turning it into a Hello world application.
For now, create a directory hello in src/cmds and add there two files:
hello.c file
/**
* Plain C Hello World application.
*/
#include <stdio.h>
int main(int argc, char **argv) {
printf("Hello world!\n");
return 0;
}
As you can see, this is a regular C program, that doesn't use any Embox-specific APIs. Let's integrate it into Embox now.
Hello.my file
(refer to Cat.my):
package embox.cmd.hello
#AutoCmd
#Cmd(name = "hello",
help = "<This is what `help hello` will output>",
man = '''
<What is shown when running `man hello`>
''')
module hello {
source "hello.c"
depends embox.compat.libc.all // for stdio
}
Now add the newly defined module into the configuration.
conf/mods.config file
package genconfig
configuration conf {
...
include embox.cmd.hello.hello
}
Build and run
Run make. This will compile hello.c and link it with Embox appropriately. After that, run it with sudo ./scripts/qemu/auto_qemu and type hello into the embox>prompt.
That's it.
Regarding your questions
To summarize:
Embox source code is compiled (via make) into some file (Object file?), <file>.<ext>
At the same time, my app's source code is cross-compiled (somehow) into an Object file (myapp.o) that is compatible with Embox
Both your application and Embox itself are compiled together with a regular (cross-)compiler, defined in conf/build.conf through a CROSS_COMPILE variable.
Some tool combines: (a) the Embox <file>.<ext> produced by make, (b) myapp.o and (c) any other libs I specify. It takes these as inputs and produces a single application image that is ready to be flashed via JTAG
These are linked with ld as part of the build process.
What is the exact name and file extension of the Embox "artifact" produced by running make on Embox source code? Is this artifact different depending on whether you are on Windows or Mac?
The main build artifacts are build/base/bin/embox (ELF) and build/base/bin/embox.bin (binary). If I'm not mistaken, these all have the same extension on all build platforms (well, may be there will be embox.exe instead of embox, but that's unlikely).
What tools besides make are necessary to produce this artifact?
The cross-compiler, essentially. GNU Tools for ARM embedded processors is a good choice.
Plus some quirks in case of Windows (see above).
What is this magic tool that takes in Object/interim files and produces a single app image? What is the exact name and file extension of this app image?
There's no such magic tool. :)
What tools do I need to cross-compile myapp.c and myapp.h into a myapp.o that is Embox compatible?
This is, again, hidden beneath Mybuild. In a nutshell, it:
compiles myapp.c using the cross-compiler into myapp.o
if the app is defined as a #AutoCmd module, it:
registers the app in a command registry by storing a pointer to main among with some metadata like name
strips away the main symbol from the object file to prevent conflicts in case of multiple apps
links myapp.o as it were a part of Embox into embox.o and then into embox ELF
Its the first time I heard about Embox, but the tool to combine Embox with your code is obviously a linker (so a cross ld from binutils, see documentation of ld). To understand more about linkers, read Levine's book Linkers and loaders
The Embox produced by compiling Embox source code is probably a library (libembox.a), or a relocatable object file embox.o - possibly produced by ld -r).
The produced application image is probably a raw binary file (.bin) but it could be an ELF file if it is loaded by the GRUB loader.
I guess that the building process is quite similar to the Linux kernel build process.
BTW, I would imagine that developing on a Linux system could be simpler, since Linux uses the same kind of tools daily. So you might install Linux on your development laptop.
You need a cross-compiler (for your target platform) to compile your code to be combined with Embox.
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
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.