Jens Rehsack [Wed, 22 Aug 2018 09:04:24 +0000 (11:04 +0200)]
libxml-parser-perl: fix "...contains bad RPATH"
The perl distribution "XML-Parser" relies for configuration
on the tooling of Devel::CheckLib - which is not aware of
sysroot locations nor of reasonable compiler/link definitions
from outside.
This causes
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA Issue: package libxml-parser-perl contains bad RPATH ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
package libxml-parser-perl contains bad RPATH ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib in file ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so [rpaths]
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: libxml-parser-perl-2.44-r0 do_package_qa: Function failed: do_package_qa
It's strongly encouraged to the maintainer @toddr to rework the
toolchain for up to date environments.
Jens Rehsack [Wed, 22 Aug 2018 09:04:23 +0000 (11:04 +0200)]
cpan.bbclass: adopt to recent EU::MM
The modern the time, the improvements in ExtUtils::MakeMaker.
Nowadays, .packlist and perllocal.pod aren't touched anymore when appropriate
flags set during configure stage. Controlling the flags globally avoids
dual-life recipes need share patching.
Further: remove prepending ${PERL_ARCHLIB} in PERL5LIB - it's wrong (search
order is site_lib, vendor_lib, core) - and ${PERL_ARCHLIB} contains core
libpath only ...
Hongzhi.Song [Wed, 22 Aug 2018 08:37:12 +0000 (01:37 -0700)]
cryptodev-linux: Fixes a kernel crash observed with cipher-gcm test
The crypto API for AEAD ciphers changed in recent kernels, so that
associated data is now part of both source and destination scatter
gathers. The source, destination and associated data buffers need
to be stiched accordingly for the operations to succeed.
Hongxu Jia [Wed, 22 Aug 2018 09:16:42 +0000 (17:16 +0800)]
mtools: fix race issue while mtools invoked frequently
While invoking mtools frequently, the unblocking request
caused race issue. Here is an example of syslinux
[snip]
dd if=/dev/zero of=floppy.img bs=1024 count=144
losetup /dev/loop1 floppy.img
mkdosfs /dev/loop1
syslinux -i /dev/loop1
|plain floppy: device "/proc/6351/fd/3" busy (Resource temporarily unavailable):
|Cannot initialize 'S:'
|Bad target s:/ldlinux.sys
[snip]
The idea is from:
https://bugzilla.redhat.com/show_bug.cgi?id=1235016
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-dev/bRPUCFHoBTQ/ZjB8kjjx1vUJ
oe-run-native: Add *-native directories under STAGING_BINDIR_NATIVE to PATH environment
It helps to find/use native tools under ${STAGING_BINDIR_NATIVE}/*-native.
Solving below error:
$ oe-run-native python3-native python3
Running bitbake -e python3-native
Error: Unable to find 'python3' in .../tmp/work/x86_64-linux/python3-native/3.5.5-r1.0/recipe-sysroot-native/usr/bin:.../tmp/work/x86_64-linux/python3-native/3.5.5-r1.0/recipe-sysroot-native/bin:.../tmp/work/x86_64-linux/python3-native/3.5.5-r1.0/recipe-sysroot-native/usr/sbin:.../tmp/work/x86_64-linux/python3-native/3.5.5-r1.0/recipe-sysroot-native/sbin
Error: Have you run 'bitbake python3-native -caddto_recipe_sysroot'?
-- snip --
After this change we have native python3 to be found:
$ oe-run-native python3-native python3
Running bitbake -e python3-native
Python 3.5.5 (default, Aug 8 2018, 17:45:49)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
-- snip --
Chen Qi [Mon, 20 Aug 2018 08:57:54 +0000 (16:57 +0800)]
cmake-native: fix to function correctly in case of eSDK
Our eSDK is expected to provide traditional SDK's functionality. But
for cmake, it could not function well in eSDK.
This problem is discovered by the assimp.py test case. The error message
is as below.
testsdkext/tmp/sysroots/x86_64/usr/lib/libz.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
The problem is about cmake-native being unable to find the correct lib.
nativesdk-cmake has solved this problem. So make use of the solution to
solve the eSDK problem.
Richard Purdie [Tue, 21 Aug 2018 21:45:31 +0000 (21:45 +0000)]
oeqa/context: Only set buffer mode for non-concurrent tests
Periodically we'd see:
NOTE: core-image-sato-1.0-r0 do_testsdk: ======================================================================
NOTE: core-image-sato-1.0-r0 do_testsdk: ERROR: broken-runner
NOTE: core-image-sato-1.0-r0 do_testsdk: ----------------------------------------------------------------------
NOTE: core-image-sato-1.0-r0 do_testsdk: testtools.testresult.real._StringException: Traceback (most recent call last):
File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips/build/meta/lib/oeqa/core/utils/concurrencytest.py", line 122, in _run_test
test.run(process_result)
File "/usr/lib/python3.6/site-packages/subunit/__init__.py", line 1194, in run
protocol = TestProtocolServer(result, self._passthrough, self._forward)
File "/usr/lib/python3.6/site-packages/subunit/__init__.py", line 514, in __init__
stream = stream.buffer
AttributeError: '_io.StringIO' object has no attribute 'buffer'
which seems to occur if a result arrives before all the runner threads
have started. The runner's result handling changes sys.stdout to a buffer
temporarily which can be seen in other threads and it can sometimes fail.
Since the tests are running in a separate process we don't need this buffer
handling in the concurrent case so only set when not parallelising. The
concurrent class handle setting buffer mode internally.
Richard Purdie [Tue, 21 Aug 2018 18:28:32 +0000 (18:28 +0000)]
oeqa/concurrencytest: Ensure subunit streams are flushed at exit
Without this, error output such as that in the teardown can be lost
and processes may recieve signals they're not expecting causing other
strange errors.
poky.conf: Enable security flags+pie by defaultEnable security flags+pie by default
This has been an opt-in for so long, some distributions e.g.
poky-lsb uses it by default however, since most of linux
distros have started to default to these settings for security
enhancements, time has come for OE to make it default too
Hongxu Jia [Tue, 21 Aug 2018 05:44:55 +0000 (13:44 +0800)]
python/python3: add virtual/crypt to DEPENDS
Since `6146b8c glibc: Disable crypt support in glibc' in oe-core,
python2/3 could not find symbol crypt which caused import crypt failed.
[snip]
>>> import crypt
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.5/crypt.py", line 3, in <module>
import _crypt
ImportError: /usr/lib64/python3.5/lib-dynload/_crypt.cpython-35m-x86_64-linux-gnu.so: undefined symbol: crypt
[snip]
Add virtual/crypt to DEPENDS, and python's build system (setup.py)
will search libcrypt.so in recipe-sysroot and add `-lcrypt' if it
exists.
remove the indirect dependcy of autoconf-archive-native via
SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed
into sysroot, which may cause compile problem.
Martin Jansa [Sun, 19 Aug 2018 22:16:02 +0000 (22:16 +0000)]
kernel-artifact-names.bbclass: Add 2 more variables to make it easier to change all names with one variable
* some people don't like the ${MACHINE} in the symlink, because now the DEPLOYDIR already
contains ${MACHINE} subdirectory, add KERNEL_ARTIFACT_LINK_NAME variable to change it
in one place without the need to list all variables for various artifacts
Martin Jansa [Sun, 19 Aug 2018 22:16:01 +0000 (22:16 +0000)]
kernel-artifact-names.bbclass, kernel.bbclass: remove prefix and extension from MODULE_TARBALL_* variables
* for consistency with other artifacts variables, include only the version string, not the actual name or extension
* changing .tgz to something else in the MODULE_TARBALL_NAME variable only wouldn't make much sense
because then kernel.bbclass still calls "tar -cvzf" to create it
Martin Jansa [Sun, 19 Aug 2018 22:16:00 +0000 (22:16 +0000)]
kernel*.bbclass: rename *_SYMLINK_NAME variables to *_LINK_NAME and *_BASE_NAME to *_NAME
* for consistency with IMAGE_NAME and IMAGE_LINK_NAME
and to avoid confusion with IMAGE_BASENAME (which is the
actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME
was only the version suffix)
Martin Jansa [Sun, 19 Aug 2018 22:15:58 +0000 (22:15 +0000)]
bitbake.conf, kernel-artifact-names.bbclass: introduce IMAGE_VERSION_SUFFIX instead of using DATETIME directly
* this makes it easier to use different version string than DATETIME, e.g. set from jenkins job
while keeping the suffix consistent across all artifacts stored in DEPLOYDIR
Wang Quanyang [Fri, 17 Aug 2018 15:01:37 +0000 (11:01 -0400)]
weston-init: run login before start weston.service
When systemd start the weston.service, the script "weston-start" will
check if the dir "XDG_RUNTIME_DIR" (usually is /run/user/0) exits and
create it. Then weston will create a socket file "wayland-0" for communications
with clients in this dir.
If systemd is built with enabling "pam" feature, the login will call "run-user-0.mount"
to mount tmpfs at the dir "/run/user/0", then the socket file "wayland-0" will be
missing since it is created in the old "/run/user/0".
So add "PAMName=login" to let weston.service call login first, once tmpfs is mounted at
"/run/user/0", then call weston-start to create a socket file in it.
Andre McCurdy [Fri, 17 Aug 2018 04:43:36 +0000 (21:43 -0700)]
openssl: fix path in nativesdk environment-setup script
A single version of the openssl.sh environment-setup script is
currently shared by both the openssl 1.0 and 1.1 recipes. The libdir
path in the script needs to be tweaked for openssl 1.1.
Andre McCurdy [Fri, 17 Aug 2018 04:43:35 +0000 (21:43 -0700)]
openssl: move the libdir openssl.cnf symlink into the openssl package
The openssl 1.0 recipe puts the libdir symlink to /etc/ssl/openssl.cnf
in the base openssl package (along with the libdir symlinks to
/etc/ssl/certs and /etc/ssl/private). Keep the openssl 1.1 recipe
aligned with that approach until there's a clear reason to do
something else. For more background, see comments in the following
thread:
Andre McCurdy [Fri, 17 Aug 2018 04:43:32 +0000 (21:43 -0700)]
openssl: update 32bit x86 target from linux-elf -> linux-x86
According to comments in Configurations/10-main.conf, the linux-elf
target is "... to be used on older Linux machines where gcc doesn't
understand -m32 and -m64".
The linux-x86 target appears to be the newer replacement (currently
the only difference between the two is that linux-x86 adds -m32 to
cflags).
Khem Raj [Sun, 19 Aug 2018 17:23:41 +0000 (10:23 -0700)]
libidn2: Fix libunistring detection
libunistring is one such library which many autotooled packages
mistake to use from build system if its installed on it. This
is specifically toxic when build host arch is same as target arch
since we only see the problem during runtime but thankfully OE
has build time QA which warns about it.
QA Issue: libidn2: The compile log indicates that host include and/or library paths were used.
Using --with-libunistring-prefix nudges the autoconf system for the
component to first look into target sysroot before going on to search
on the build host
Khem Raj [Sun, 19 Aug 2018 17:23:37 +0000 (10:23 -0700)]
llvm: Use YOCTO_ALTERNATE_MULTILIB_NAME environment variable in llvm-config
llvm-config is a tool on similar veins as pkg-config but provides a lot
more information and packages which use llvm e.g. mesa use this tool to
poke for llvm related informaiton e.g. version, libpath, includepaths
to name a few, this has few challanges in cross build environments where
llvm-config is supposed to be build for buildhost but provide information
about target llvm which is addressed by building native llvm-config along
with target llvm build, but this is frowned upon by OE build system since
it detects that host paths are being used so we have to build it as part
of llvm-native but then it means install paths for llvm and llvm-native
are different and wrong paths get reported when llvm-config is used.
This is solved by providing YOCTO_ALTERNATE_EXE_PATH variable to let
llvm-config use that path instead of self-relative path to report back
Second problem is when building multi-lib packages base_libdir is different
for target packages but native llvm-config does not know about it so
it reports non-multilibbed paths as libdir and packages can not find
llvm in sysroot. This is fixed by adding another environment variable
YOCTO_ALTERNATE_MULTILIB_NAME which can be set from recipes to set
proper multilib path
Khem Raj [Sun, 19 Aug 2018 17:23:35 +0000 (10:23 -0700)]
llvm: Point llvm-config to one built with llvm-native
If not defined, llvm build system tries to build one
which then confuses the OE QA system since its building
native tool and target packages in same package build
moreover it is not required since we already have it via
llvm-native
Fixes
ERROR: llvm-6.0-r0 do_package_qa: QA Issue: llvm: The compile log indicates that host include and/or library paths were used.
Khem Raj [Sun, 19 Aug 2018 17:23:34 +0000 (10:23 -0700)]
powerpc: Remove pie flags from compiler cmdline
Original approach to add -no-<pie> flags cause link time behavior changes
where packages start to lose the -fPIC -DPIC in compiler cmdline and this
list keeps growing as we build more and more packages,
Instead lets just remove the options we dont need from SECURITY_CFLAGS
this makes it more robust and less intrusive
This also means we do not need to re-add pic options as we started to do
for affected packages
David Reyna [Thu, 16 Aug 2018 01:04:09 +0000 (18:04 -0700)]
bitbake: Toaster: Implement the project-specific feature and releated enhancements and defects.
Here is the primary driving enhancement:
* Bug 12785 - Support Project Specific configuration for external
tools (e.g. ISS, Eclipse)
- Isolated project-specific configuration page (full Toaster context
hidden)
- Support for new project, reconfigure existing project, and import
existing command line project
- Ability to define variables (e.g. image recipe) and pass them back
to external GUI
- Ability to execute the cloning phase, so that external GUI receive
a buildable project
- Ability to call back to the external GUI when updates are completed
and ready
- Compatibility of above projects with the normal full Toaster interface
- Ability to pass to a 'complete' or 'cancel' web page so that the
external GUI can immediately stop that Toaster instance, and not
leave dangling servers nor edit sessions open
Here are the supporting enhancements, where at least the
back end is implemented:
* Bug 12821 - Make Toaster conf changes compatible with command line usage
* Bug 12822 - Support importing user changes to conf files into Toaster
* Bug 12823 - Support importing user build directories into Toaster
* Bug 12824 - Scan imported layers for content so that they are
immediately available
* Bug 12825 - show layer clone item in progress bar
Here are defects fixed:
* Bug 12817 - builddelete.py requires explicit 'add_arguments'
* Bug 12818 - Remove orphaned imported layers when project is deleted
* Bug 12826 - fix imported layer management
* Bug 12819 - build using selected bitbake env, not Toaster's env
* Bug 12820 - Toaster randomizes the layer order in toaster_bblayers.conf
Bruce Ashfield [Sun, 19 Aug 2018 02:50:44 +0000 (22:50 -0400)]
kernel-devsrc: restructure for out of tree (and on target) module builds
The existing kernel-devsrc package starts with a full copy of the kernel
source and then starts to strip out elements that are not required.
This results in extra time (I/O) and extra space being taken up in the
final package. The main purpose of the kernel-devsrc package has been to
build modules against the running kernel, not to include a full copy of
the source code for re-building the kernel. The end result was a
600M kernel-devsrc package.
This restructuring of the package uses an approach similar to other
distros, where the kernel-devsrc package is for building against the
running kernel and uses a curated set of copied infrastructure, versus
a mass copy of the entire kernel.
The differences in this approach versus other is largely due to the
architecture support and the split build/source directory of the
kernel.
The result is a kernel-devsrc package of about 10M, which is capable
of running "make scripts" and compiling kernel modules against the
running kernel.
Along with the changes to the copying of the infrascture, we also
have the following changes:
- a better/more explicit listing of dependencies for on-target
builds of "make scripts" or "make modules_prepare"
- The kernel source is installed into /lib/modules/<version>/build
and a symlink created from /usr/src/kernel to the new location.
This aligns with the standard location for module support
code
- There is also a symlink from /lib/modules/<version>/source -> build
to reserve a spot for a new package that is simply the kernel
source. That package is not part of this update.
Maxin B. John [Thu, 16 Aug 2018 10:41:30 +0000 (13:41 +0300)]
vala: refresh patch
Refresh the following patch:
"disable-graphviz.patch" to fix this warning:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
checking file configure.ac
checking file libvaladoc/Makefile.am
checking file libvaladoc/html/basicdoclet.vala
checking file libvaladoc/html/htmlmarkupwriter.vala
Hunk #1 succeeded at 51 with fuzz 1 (offset 8 lines).
Chen Qi [Thu, 16 Aug 2018 10:37:58 +0000 (18:37 +0800)]
glibc: re-package for libnss-db
On other distros like ubuntu/centos, libnss-db usually provides:
- The libraries
- The Makefile to create database
(in /var/db for centos, /var/lib/misc/ for ubuntu)
- The makedb command (it's in glibc-common for centos7)
What we had is:
- The libraries are in glibc-extra-nss
- The Makefile is removed
- The makedb command is in glibc-utils (lack of dependency)
So when glibc-extra-nss is installed but glibc-utils is not,
we see error like:
nscd[165]: 165 checking for monitored file `/var/db/group.db': No such file or directory
nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such file or directory
And there is not an easy way to create these databases.
To fix the issue:
- Re-package the libraries into libnss-db
- Don't remove the Makefile and add it in libnss-db
- Add RDEPENDS for libnss-db on glibc-utils
- Provide a shell script, makedbs.sh, to generate the db files.
This is to avoid dependency on 'make'.
Notes:
1. For external toolchain, an extra package 'libnss-db' need to be provided
If replacing glibc from core.
2. I've check the git history of nss/db-Makefile, the last two functionality
fix is as below.
- fix non-portable `echo -n` usage -- Date: Thu Aug 6 04:14:20 2015 -0400
- Fix db makefile rule for group.db -- Date: Fri Nov 11 14:43:36 2011 +0100
So I think this file is stable enough. And using makedbs.sh which is crafted according
to that file is not likely to cause maintanence problem.
Hongzhi.Song [Thu, 16 Aug 2018 07:38:48 +0000 (00:38 -0700)]
runtime selftest: limit kernel hw bp arches
1. So far, only qemux86[-64] support hw breakpoint, no matter whether or
not with kvm.
qemuppc: The oe-core configuration uses a PPC G4 system as the
default cpu but qemu doesn't simulate the hw breakpoint register for G4.
qemuarm: The arch more than v7 supports hw breakpoint, however arm use
v5 as default.
qemuarm64: We temporarily drop qemuarm64 for the moment. Normally it
will print debug info once, but endlessly when we trigger the break
point. Now it is hard to located the issue, but we will confirm it
later.
qemumips*: Kernel dosen't support hw bp for mips.
2. Syslog maybe not started, so we use dmesg to confirm.
3. Running 'ls' to trigger the hardware breakpoint test.
Anuj Mittal [Thu, 16 Aug 2018 06:26:33 +0000 (14:26 +0800)]
python3: enable profile optimized builds
Enable profile guided optimization (pgo) for python3. Enabling pgo in
python is generally as simple as invoking the target profile-opt which:
- builds python binaries with profile instrumentation enabled,
- runs a specific profile task using that python to get the profile
data and,
- feeds the compiler with this profile data and rebuilds python.
This change invokes qemu-user for the second step of running a profile
task using target python. Depending on how long profile task takes to
run, this might add a significant time to compilation (which would be
true for native builds too). The default profile task can be changed by
the users depending on what makes sense for their use case (or can be
left empty). In case qemu-user isn't supported, profile task won't be run.
Avoid adding bison-native to the sysroot without a specific
dependency in the recipe. This means indirect dependencies
(e.g. X -> Y -> binutils-cross -> bison-native) no longer meet the
dependency incidentally. This improves determinism and avoids build
failures when people switch to external toolchains.
Based on an idea by Richard Purdie:
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html
Robert Yang [Thu, 16 Aug 2018 02:25:46 +0000 (10:25 +0800)]
prelink: use ehdr.e_shstrndx as index rather than ehdr.e_shnum
[YOCTO #12791]
According to struct elf32_hd, the e_shnum is section header number, and the
index is e_shstrndx, not e_shnum.
This can fix segmention fault when handle libqb.so.0.18.2 from libqb_1.0.3.
It fails to handle libqb.so.0.18.2 and get errors:
Symbol section index outside of section numbers
Then segmentation fault, this is because the e_shnum is 34, while e_shstrndx is
27 (it would be 33 when no errors), I've checked several elf files to confirm
that the ones after e_shstrndx is NULL, so use e_shstrndx should be correct.
Fixed:
MACHINE="qemux86-64"
IMAGE_INSTALL_append = " libqb" #libqp is from meta-openembedded
$ bitbake core-image-minimal
Segmention fault
Robert Yang [Thu, 16 Aug 2018 02:54:39 +0000 (10:54 +0800)]
binutils: Improve check for input file matching output file
When the assembler reports that the input and output are the same, report the
file names involved, in order to help debugging. Also do not equate two files
are the same if the have the same inode value but reside on different file
systems.
bb.utils.copyfile is called in a few places with identical src and dst
in order to create an st_nlinks==1 version of the file. That that even
works relies on an implementation detail of copyfile (namely, that it
creates a temporary file and then does a rename). Moreover, it's a waste
of time if the file already has st_nlinks==1.
So create a helper that optimizes away the copy in the st_nlinks==1
case. Of course, this helper relies on the same implementation detail,
but that's now contained within bb.utils itself.
To test that we do at least sometimes hit the no-copy path, I tested
locally with
This class sets POSTINST_INTERCEPTS and POSTINST_INTERCEPTS_CHECKSUMS,
to allow us to pull intercepts from BBPATH. This is kept as a separate
class, as it's needed by both image construction and sdk construction,
the latter to support meta-toolchain & similar recipes.
oe.package_manager: support loading intercepts from multiple paths
- if POSTINST_INTERCEPTS is set, use the listed intercept files, or
- if POSTINST_INTERCEPTS_PATH is set, load from the listed paths, or
- if POSTINST_INTERCEPTS_DIR is set, load from it (for compatibility), or
- load from ${COREBASE}/meta/postinst-intercepts
André Draszik [Tue, 22 May 2018 12:25:50 +0000 (13:25 +0100)]
sstate: allow specifying indirect dependencies to exclude from sysroot
Currently, a dependency on any -native recipe will pull in
all dependencies of that -native recipe in the recipe
sysroot. This behaviour might not always be wanted, e.g.
when that -native recipe depends on build-tools that are
not relevant for the current recipe.
This change adds a SSTATE_EXCLUDEDEPS_SYSROOT variable,
which will be evaluated for such recursive dependencies to
be excluded. The idea is similar to
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html
except that the list is not hard-coded anymore.
SSTATE_EXCLUDEDEPS_SYSROOT is evaluated as two regular
expressions of recipe and dependency to ignore, e.g. in
the above flex-native / bison-native use-case, one would
specify
Another anticipated user is meta-java, where certain newer
JDKs can only be bootstrapped (built) using older JDKs,
but it doesn't make much sense to copy all those older
JDKs and their own build tools (ant, etc.) into the
sysroot of recipes wanting to be built using the newer JDK
(only), e.g.:
Khem Raj [Wed, 15 Aug 2018 01:40:05 +0000 (18:40 -0700)]
security_flags: Add PIC to cflags for some recipes on ppc
Fixes issues related out of range R_PPC_REL24
e.g.
/usr/lib/xorg/modules/input/libinput_drv.so: /usr/lib/libinput.so.10: R_PPC_REL24 relocation at 0x0e8602c4 for symbol `libevdev_has_event_code' out of range
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrej Valek [Tue, 17 Jul 2018 09:10:34 +0000 (11:10 +0200)]
openssl-1.1: rework packaging
The main idea is to have libssl and libcrypto in separate packages.
This saves space if only single library is needed and also some recipes
(in other layers) depend on these library packages.
Together with this other packages like in 1.0.x were created.
The only difference is that openssl 1.1 has additional package openssl-bin.
Add missing dependency to perl for openssl-bin pkg, c_rehash requires it.
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrej Valek [Tue, 17 Jul 2018 09:10:33 +0000 (11:10 +0200)]
openssl-1.1: fix c_rehash perl errors
Patch original c_rehash script with Debian patch instead
of overriding it with own version.
Error output from c_reshah without patching:
Unknown regexp modifier "/b" at ./c_rehash line 15, at end of line
Unknown regexp modifier "/W" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/3" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/2" at ./c_rehash line 28, at end of line
No such class installdir at ./c_rehash line 63, near "Prefix our
installdir"
(Might be a runaway multi-line // string starting on line 28)
syntax error at ./c_rehash line 63, near "Prefix our installdir"
Can't redeclare "my" in "my" at ./c_rehash line 68, near ""
Execution of ./c_rehash aborted due to compilation errors.
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
