Build ffmpeg using yocto - build

I am trying to build ffmpeg for an ARM SoC. Therefore I am using yocto with following recipe:
SUMMARY = "FFMPEG"
HOMEPAGE = "http://ffmpeg.org"
LICENSE = "GPLv2"
#LIC_FILES_CHKSUM = "file://COPYING.GPLv2"
#SECTION = "net"
#DEPENDS = "sqlite3-native glib-2.0 zlib libpcre spawn-fcgi fcgi"
S = "${WORKDIR}/git"
SRCREV = "${AUTOREV}"
SRC_URI = "git://source.ffmpeg.org/ffmpeg.git;branch=release/2.8 \
"
PACKAGECONFIG[--build] = ""
EXTRA_OECONF = " \
--extra-ldflags=-static \
--extra-cflags=-static \
--disable-mipsfpu \
--disable-mips32r2 \
--disable-mipsdspr1 \
--disable-mipsdspr2 \
--enable-bzlib \
--enable-zlib \
"
inherit autotools pkgconfig
Building this recipe throws following errer:
Unknown option "--build=x86_64-linux`
How can I remove this configuration flag from do_configure?
Or is there any other way to build ffmpeg?

If you're using yocto (as you said) it would be best to simply include the ffmpeg package in your image using:
IMAGE_INSTALL += "ffmpeg"
This should work because ffmpeg is available in the poky repository.
If you need a specific version of ffmpeg, IMHO it is the best way to adapt the available recipe to your needs.

Related

How Can I Install libcrypto++6 (or libcrypto++8) and default-jre-headless

how can I install “libcrypto++6 (or libcrypto++8)” with yocto? Normally, I would add debian source.list after installation and install it with apt, but it causes many problems. Likewise, I want to install “default-jre-headless”. I use Kirkstone. I was adding those that do not have such recipes from the source code, but the source code of these is difficult to find and I did not know how to make the recipes. Below is a recipe I found for libcrypto++6, but it doesn’t work.
HOMEPAGE = "http://www.cryptopp.com/wiki/Main_Page"
BUGTRACKER = "http://sourceforge.net/apps/trac/cryptopp/"
SECTION = "libs"
LICENSE = "BSL-1.0"
LIC_FILES_CHKSUM = "file://License.txt;md5=deb6d182b0f7f8a866c42941b9f014c4"
BBCLASSEXTEND = "native nativesdk"
PR = "r1"
PVSHORT = "${#'${PV}'.replace('.','')}"
SRC_URI = " \
https://sourceforge.net/projects/cryptopp/files/cryptopp/5.6.4/cryptopp564.zip;subdir=libcryptopp-${PV} \
file://0001-Fix-cross-compilation.patch \
"
SRC_URI[md5sum] = "4ee7e5cdd4a45a14756c169eaf2a77fc"
SRC_URI[sha256sum] = "be430377b05c15971d5ccb6e44b4d95470f561024ed6d701fe3da3a188c84ad7"
inherit autotools-brokensep pkgconfig
EXTRA_OECONF = "--libdir=${base_libdir}"
#we want tegrarcm binary to run on a 32-bit architecture, on x86_64 this requires the 32-bit compatibility libs
EXTRA_OEMAKE_class-native = "CC='${CC} -m32' CXX='${CXX} -m32'"
do_compile() {
sed -i -e 's/^CXXFLAGS/#CXXFLAGS/' GNUmakefile
export CXXFLAGS="${CXXFLAGS} -DNDEBUG -fPIC"
oe_runmake -f GNUmakefile
oe_runmake libcryptopp.a
}
do_install:prepend() {
export PREFIX=${prefix}
}
do_install:append() {
if [ -f "${D}/usr/lib/libcryptopp.so" ] && [ ! -e "${D}/usr/lib/libcryptopp.so.${PV}" ]
then
mv ${D}/usr/lib/libcryptopp.so ${D}/usr/lib/libcryptopp.so.${PV}
ln -fs libcryptopp.so.${PV} ${D}/usr/lib/libcryptopp.so.5
ln -fs libcryptopp.so.${PV} ${D}/usr/lib/libcryptopp.so
fi
}

bazel test vs direct execution

I'm using GoogleTest with bazel and when I run bazel test :tokens_test (rule defined below) I have a failing test, but when I run the compiled tests I see the expected result. It is failing because the test can not open the test data file. The directory layout and the BUILD rule for the test I'm running look like this:
tokens/
BUILD
tokens_test.cpp
test_data/
test_input1.txt
cc_test(
name = "tokens_test",
srcs = ["tokens_test.cpp"],
deps = [
'#gtest//:gtest'
'#gtest//:gtest_main',
],
data = ["//tokens/test_data:test_input1.txt"]
)
At this point the test is just a wrapper to open the file and read in the test data which is the bit thats failing.
TEST(Tokenizer, OpenFileTest) {
auto fin = std::ifstream("test_data/test_input1.txt");
std::cout << a.get(); // Outputs -1.
}
When I navigate to the bazel-out location and find my way to the tokens runfiles directory I can see the compiled test excutable.
[jibberish]/__main__/tokens>ls
test_data/
test_input1.txt
tokens_test
And when I run the executable:
[jibberish]/__main__/tokens>./tokens_test
...normal test output...
The correct output!
...more test output...
I'm lost as to where to start looking for the problem. I've tried including a BUILD in the test_data directory with an exports_files rule, using a variety of relatives paths in the BUILD files and my source code and a lot of permutations of those relative paths.
Define your data as
data = ["test_data/test_input1.txt"]
Use absolute path: ./tokens/test_data/test_input1.txt
To find it run your test with a bazel test --sandbox_debug -s. The last command will looks like that one:
SUBCOMMAND: # //:hello_test [action 'Testing //:hello_test', configuration: faff19e6fd939f490ac11578d94024c6b7a032836cde039fd5edd28b838194e8, execution platform: #local_config_platform//:host]
(cd /home/s/.cache/bazel/_bazel_s/fa4c7c7c7db2888182e4f15990b55d58/execroot/com_google_absl_hello_world && \
exec env - \
EXPERIMENTAL_SPLIT_XML_GENERATION=1 \
RUNFILES_DIR=bazel-out/k8-fastbuild/bin/hello_test.runfiles \
RUN_UNDER_RUNFILES=1 \
TEST_BINARY=./hello_test \
TEST_INFRASTRUCTURE_FAILURE_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.infrastructure_failure \
TEST_LOGSPLITTER_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.raw_splitlogs/test.splitlogs \
TEST_PREMATURE_EXIT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.exited_prematurely \
TEST_SIZE=medium \
TEST_SRCDIR=bazel-out/k8-fastbuild/bin/hello_test.runfiles \
TZ=UTC \
XML_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.xml \
external/bazel_tools/tools/test/test-setup.sh ./hello_test)
Then you can paste the whole (cd ...) one-liner to reproduce the exact sandbox environment as during the bazel test run. For example you can substitute the last line in that way:
(cd /home/s/.cache/bazel/_bazel_s/fa4c7c7c7db2888182e4f15990b55d58/execroot/com_google_absl_hello_world && \
exec env - \
EXPERIMENTAL_SPLIT_XML_GENERATION=1 \
RUNFILES_DIR=bazel-out/k8-fastbuild/bin/hello_test.runfiles \
RUN_UNDER_RUNFILES=1 \
TEST_BINARY=./hello_test \
TEST_INFRASTRUCTURE_FAILURE_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.infrastructure_failure \
TEST_LOGSPLITTER_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.raw_splitlogs/test.splitlogs \
TEST_PREMATURE_EXIT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.exited_prematurely \
TEST_SIZE=medium \
TEST_SRCDIR=bazel-out/k8-fastbuild/bin/hello_test.runfiles \
TZ=UTC \
XML_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/hello_test/test.xml \
bash -c 'pwd && ls')
So bash -c 'pwd && ls' will show the current directory path and content.

conan make generator does not set CONAN_CXXFLAGS as expected

When running conan install . -s arch=x86 on an x86_64 System, I expect a compiler option like CONAN_CXXFLAGS_MYLIB=-m32 in the generated conanbuildinfo.mak file, but there is no such an option.
First, the contents of the conanfile.txt:
[requires]
mylib/1.0#demo/dev
[generators]
make
Here is the output of the install command (cmake has special treatment, because it is only a tool):
$ conan install . -s cmake:arch=x86_64 -s arch=x86
Configuration:
[settings]
arch=x86
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
cmake:arch=x86_64
[options]
[build_requires]
[env]
conanfile.txt: Installing package
Requirements
mylib/1.0#demo/dev from local cache - Cache
Packages
mylib/1.0#demo/dev:eb79ce42f6e6b4359bd7d0a65a238a4dae953257 - Cache
'''
Cross-build from 'Linux:x86_64' to 'Linux:x86'
Installing (downloading, building) binaries...
mylib/1.0#demo/dev: Already installed!
conanfile.txt: Generator make created conanbuildinfo.mak
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
The generated makfe file looks like this:
#-------------------------------------------------------------------#
# Makefile variables from Conan Dependencies #
#-------------------------------------------------------------------#
CONAN_ROOT_MYLIB ?= \
/home/username/.conan/data/mylib/1.0/demo/dev/package/eb79ce42f6e6b4359bd7d0a65a238a4dae953257
CONAN_SYSROOT_MYLIB ?= \
CONAN_INCLUDE_DIRS_MYLIB += \
/home/username/.conan/data/mylib/1.0/demo/dev/package/eb79ce42f6e6b4359bd7d0a65a238a4dae953257/include
CONAN_LIB_DIRS_MYLIB += \
/home/username/.conan/data/mylib/1.0/demo/dev/package/eb79ce42f6e6b4359bd7d0a65a238a4dae953257/lib
CONAN_BIN_DIRS_MYLIB += \
CONAN_BUILD_DIRS_MYLIB += \
/home/username/.conan/data/mylib/1.0/demo/dev/package/eb79ce42f6e6b4359bd7d0a65a238a4dae953257/
CONAN_RES_DIRS_MYLIB += \
CONAN_LIBS_MYLIB += \
mylib
CONAN_SYSTEM_LIBS_MYLIB += \
CONAN_DEFINES_MYLIB += \
CONAN_CFLAGS_MYLIB += \
CONAN_CXXFLAGS_MYLIB += \
CONAN_SHAREDLINKFLAGS_MYLIB += \
CONAN_EXELINKFLAGS_MYLIB += \
CONAN_FRAMEWORKS_MYLIB += \
CONAN_FRAMEWORK_PATHS_MYLIB += \
CONAN_ROOTPATH += \
$(CONAN_ROOTPATH_MYLIB)
CONAN_SYSROOT += \
$(CONAN_SYSROOT_MYLIB)
CONAN_INCLUDE_DIRS += \
$(CONAN_INCLUDE_DIRS_MYLIB)
CONAN_LIB_DIRS += \
$(CONAN_LIB_DIRS_MYLIB)
CONAN_BIN_DIRS += \
$(CONAN_BIN_DIRS_MYLIB)
CONAN_BUILD_DIRS += \
$(CONAN_BUILD_DIRS_MYLIB)
CONAN_RES_DIRS += \
$(CONAN_RES_DIRS_MYLIB)
CONAN_LIBS += \
$(CONAN_LIBS_MYLIB)
CONAN_DEFINES += \
$(CONAN_DEFINES_MYLIB)
CONAN_CFLAGS += \
$(CONAN_CFLAGS_MYLIB)
CONAN_CXXFLAGS += \
$(CONAN_CXXFLAGS_MYLIB)
CONAN_SHAREDLINKFLAGS += \
$(CONAN_SHAREDLINKFLAGS_MYLIB)
CONAN_EXELINKFLAGS += \
$(CONAN_EXELINKFLAGS_MYLIB)
CONAN_FRAMEWORKS += \
$(CONAN_FRAMEWORKS_MYLIB)
CONAN_FRAMEWORK_PATHS += \
$(CONAN_FRAMEWORK_PATHS_MYLIB)
CONAN_SYSTEM_LIBS += \
$(CONAN_SYSTEM_LIBS_MYLIB)
#-------------------------------------------------------------------#
Conan knows, that this is a cross-build, it knows the compiler, it builds mylib with 32 bitness (or takes the 32 bit binaries, if found in the repo). So it should be obvious, that my app needs to be compiled with -m32.
Why is my expectation wrong?
UPDATE:
I have found the solution myself. If a conanfile.py is used with the autotools/make helper instead of the simple conanfile.txt, then it is possible to build the app with conan build ., and conan sets all compiler options and defines correctly. Here is an example of such a consumer receipt:
from conans import ConanFile, AutoToolsBuildEnvironment
from conans import tools
class AppConan(ConanFile):
name = "mayapp"
version = "1.0"
settings = "os", "compiler", "build_type", "arch"
requires = "mylib/1.0#demo/dev"
generators = "make", "virtualrunenv"
def build(self):
atools = AutoToolsBuildEnvironment(self)
atools.make()

Qt migrating from Qt 4 to 5, pri file not included during qmake

I am migrating a project from qt 4.8.6 to qt 5.3.2.
I have a pro file which is like this:
...
#
# External library configuration
#
include(QGCExternalLibs.pri)
#
# Post link configuration
#
include(QGCSetup.pri)
...
and the QGCExternalLibs.pri is simply something like:
#
# Add in a few missing headers to windows
#
WindowsBuild {
INCLUDEPATH += libs/lib/msinttypes \
libs/thirdParty/opencv/include
LIBS += -L$$BASEDIR/libs/thirdParty/opencv/x86/vc10/lib
LIBS += opencv_core231d.lib \
opencv_highgui231d.lib \
opencv_video231d.lib \
opencv_imgproc231d.lib \
opencv_ml231d.lib \
opencv_features2d231d.lib \
opencv_flann231d.lib \
opencv_calib3d231d.lib \
opencv_objdetect231d.lib \
opencv_ts231d.lib
}
However, when I run qmake -tp vc xxxxx.pro the .pro file is qmaked successfully, however, the .pri file is not included at all. What should I do in this case?

Qmake creating a .pc file

Does anyone know if qmake can create a .pc file? I found someone that said it could here: http://www.qtcentre.org/threads/24422-How-can-we-create-.pc-file-automatically. But I have tried it and got the same results as the person having the issue at the bottom of the thread. I was wondering if someone knew anything about this.
TEMPLATE = lib
TARGET = proc_Model
QT += declarative dbus
CONFIG += qt plugin dbus create_pc
DESTDIR = /usr/lib/
OBJECTS_DIR = .obj
MOC_DIR = .moc
TARGET = $$qtLibraryTarget($$TARGET)
INCLUDEPATH += ../common
# Input
SOURCES += ../common/proc_struct.cpp \
listitem.cpp \
listmodel.cpp \
process.cpp \
proc_if.cpp
HEADERS += ../common/proc_struct.h \
listitem.h \
listmodel.h \
process.h \
proc_if.h
headers.path= /usr/include/proc_Model
headers.files = ../common/proc_struct.h \
listitem.h \
listmodel.h \
process.h \
proc_if.h
target.path = /usr/lib
QMAKE_PKGCONFIG_NAME = proc_Model
QMAKE_PKGCONFIG_DESCRIPTION = Model that emits process info
QMAKE_PKGCONFIG_LIBDIR = $$target.path
QMAKE_PKGCONFIG_INCDIR = $$target.path
QMAKE_PKGCONFIG_DESTDIR = pkgconfig
INSTALLS+=headers target
When I make install, I get the following output:
install -m 755 -p "/usr/lib/libproc_Model.so" "/usr/lib/libproc_Model.so"
install: `/usr/lib/libproc_Model.so' and `/usr/lib/libproc_Model.so' are the same file
make: [install_target] Error 1 (ignored)
strip --strip-unneeded "/usr/lib/libproc_Model.so"
install -m 644 -p "/usr/lib/pkgconfig/proc_Model.pc" "/usr/lib/pkgconfig/proc_Model.pc"
install: cannot stat `/usr/lib/pkgconfig/proc_Model.pc': No such file or directory
make: [install_target] Error 1 (ignored)
According to qmake source code, you have to add:
CONFIG += create_prl no_install_prl
create_pc only adds the rule for the .pc file target to the makefile with the command "qmake -prl" and that command only creates the .pc file if the create_prl option is present.
no_install_prl prevents the unneeded .prl file, generated by create_prl, to be installed in ${target.path}.
I made a complete example here:
https://github.com/pvanhoof/dir-examples/blob/master/qmake-example/src/libs/qmake-example/qmake-example.pro
## We get the PREFIX, MAJOR_VERSION, MINOR_VERSION and PATCH_VERSION
## from this project-wide include
include(../../../qmake-example.pri)
## We will use the standard lib template of qmake
TEMPLATE = lib
## We need to set VERSION to a semver.org version for compile_libtool
VERSION = $${MAJOR_VERSION}"."$${MINOR_VERSION}"."$${PATCH_VERSION}
## According https://autotools.io/libtool/version.html, section 4.3
## we should have as target-name the API version in the library's name
TARGET = qmake-example-$${MAJOR_VERSION}"."$${MINOR_VERSION}
## We will write a define in config.h for access to the semver.org
## version as a double quoted string
QMAKE_SUBSTITUTES += config.h.in
## Our example happens to use QDebug, so we need QtCore here
QT = core
## This is of course optional
CONFIG += c++14
## We will be using libtool style libraries
CONFIG += compile_libtool
CONFIG += create_libtool
## These will create a pkg-config .pc file for us
CONFIG += create_pc create_prl no_install_prl
## Project sources
SOURCES = \
qmake-example.cpp
## Project headers
HEADERS = \
qmake-example.h
## We will install the headers in a API specific include path
headers.path = $${PREFIX}/include/qmake-example-$${MAJOR_VERSION}"."$${MINOR_VERSION}
## Here will go all the installed headers
headers.files = $${HEADERS}
## Here we will install the library to
target.path = $${PREFIX}/lib
## This is the configuration for generating the pkg-config file
QMAKE_PKGCONFIG_NAME = $${TARGET}
QMAKE_PKGCONFIG_DESCRIPTION = An example that illustrates how to do it right with qmake
# This is our libdir
QMAKE_PKGCONFIG_LIBDIR = $$target.path
# This is where our API specific headers are
QMAKE_PKGCONFIG_INCDIR = $$headers.path
QMAKE_PKGCONFIG_DESTDIR = pkgconfig
QMAKE_PKGCONFIG_PREFIX = $${PREFIX}
QMAKE_PKGCONFIG_VERSION = $$VERSION
## Installation targets (the pkg-config seems to install automatically)
INSTALLS += headers target