André Draszik a4251575f4 meta_oe_security_flags: disable PIE for libdbus-c++
The short version - it ain't working.

The long version:

For shared libraries made from C++ sources, configure
runs some code to determine how to link shared libraries
(from libtool.m4) using g++. In particular, it calls
g++ ${CFLAGS} -c conftest.c
g++ ${CFLAGS} -nostdinc -shared -v conftest.o
to then parse the gcc -v output.

If CFLAGS contains -pie -fpie, g++ adds Scrt1.o to the
objects being linked together to form the final output.

Once Scrt1.o is pulled into a shared library, it becomes
impossible to link this DSO against a final binary. I
didn't investigate why, by I suspect because of
-Wl,relro -Wl,now

libtool takes note of Scrt1.o (and all other libraries
added by gcc, but those don't matter here) and adds it
everywhere a shared library is being created, see
predep_objects= and postdep_objects= in the
'LIBTOOL TAG CONFIG: CXX' section.

In other words, the the shared library created during
the build can't be linked against. This includes
some applications that are part of the libdbus-c++
source tree, but also any other external user.

While I am not sure if the root of the issue is in
- gcc (should it really add Scrt1.o despite -shared),
  or in
- libtool (should it filter out -pie -fpie during the
  configure step), or even in
- OE (should it really be adding -pie -fpie to
  everything, even shared libraries by default and
  unconditionally),
we can make things work by using SECURITY_NO_PIE_CFLAGS
instead.

Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
2016-12-02 09:23:44 +01:00
2016-10-21 18:20:43 +02:00
2016-09-05 13:30:51 +02:00

Collection of layers for the OE-core universe

Please see the respective READMEs in the layer subdirectories

Description
No description provided
Readme 110 MiB
Languages
BitBake 85%
Shell 6.2%
C 3%
Roff 2.2%
NASL 1.9%
Other 1.5%