There is no problem in using the "insecure" CRT functions, as long as
they are used correctly - especially not within the test suite where
they are only are exposed to the test suite input data.
Within the library, these are used via the library internal wrappers
in codec/common/src/crt_util_safe_x.cpp, but we'd rather not use them
in the test suite - just use the normal standard C functions here.
This disables armasm warning A4509, "This form of conditional
instruction is deprecated".
The conditional instructions (such as movcs, addcs, subscs)
have been deprecated in ARMv8, in favor of conditional branches.
This isn't something that we need to take immediate action about,
though, therefore silence the warning.
Prior to 3f69873c99, there already was a mechanism for installing
the import library, used for the MSVC builds. Use that for mingw
as well, instead of adding more hardcoded rules.
This makes it clearer which ones actually are real platforms
(chosen automatically or explicitly via "make ARCH=foo") and which
ones just are shared helpers.
This fixes building for android on windows.
Building for android on windows still requires MSYS for running make,
but running the ndk-build of the sample projects from within MSYS
doesn't seem to work (the OS variable from the OpenH264 makefile
interferes with the host system detection in ndk-build), so one still
needs to build it in two steps, first make OS=android ... libopenh264.so,
then building the sample projects manually.
If the user selects a nonexistent ARCH, previously the call that
sets TOOLCHAINPREFIX would set it to contain a long error message,
which makes it quite hard to figure out what actually went wrong.
Instead check that CXX=$(TOLCHAINPREFIX)g++ actually points to a
working executable, and abort immediately if this isn't true.
This allows building two versions for different architectures at
the same time, without the built files clobbering each other.
This is very helpful when trying to track down differences between
two build configurations.
To build outside of the source tree, create the other directory to
use for building (either outside of the openh264 directory, or as
a subdirectory), enter that directory, and do
"make -f path/to/openh264/Makefile".
The -ZI option is only supported when building for 32 bit x86,
when building for x64 or for arm, it gives the warning "/ZI is
not supported on this platform; enabling /Zi instead".
-ZI is for "edit & continue" debugging, which one probably wouldn't
be doing with a build outside of the IDE anyway, so keep it simple
instead of trying to set -ZI specifically for x86 32 bit builds.
If the android test projects hasn't been built yet, the "make clean"
command will stop at "ant clean" (which fails since build.xml doesn't
exist yet). If this happens, one still would want to run the "make
clean" command to the end, cleaning up any possible intermediate object
files (e.g. from a build for a different platform).
This also avoids another manual edit in module/targets.mk. Now
the file is completely autogenerated by the build/mktargets.sh
script, just as all the other targets.mk files.
This matches the common naming scheme more closely for adding extra
flags to individual parts of the build.
Also deduplicate the static stlport lib name.
