Mirror of git.openembedded.org/meta-openembedded https://git.enea.com/cgit/linux/meta-openembedded.git/atom?h=pyro 2017-05-04T07:18:58+00:00 2017-05-04T07:18:58+00:00 Peter Kjellerstedt peter.kjellerstedt@axis.com 2017-04-28T14:23:07+00:00 urn:sha1:3af551405e044ec77b85f50a6a33a8ed3b56f8e4 Since libdevmapper was split out from lvm2, it now needs its own entry to disable building with -fpie. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> 2016-12-02T08:26:33+00:00 Khem Raj raj.khem@gmail.com 2016-12-01T05:47:43+00:00 urn:sha1:aac6bf8bf911c3f14ff9dce08f0f011838f5a426 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> 2016-12-02T08:23:44+00:00 André Draszik adraszik@tycoint.com 2016-11-25T15:18:03+00:00 urn:sha1:a4251575f41fa5aafe5072e562497b05c11b6702 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-11-26T00:04:53+00:00 Khem Raj raj.khem@gmail.com 2016-11-03T17:26:49+00:00 urn:sha1:bc0ea5b276629dcd1169374b8217087db2ded086 Signed-off-by: Khem Raj <raj.khem@gmail.com> 2016-11-23T14:24:00+00:00 Khem Raj raj.khem@gmail.com 2016-11-03T08:20:35+00:00 urn:sha1:4b3a210033cf240c8ef4326cd62e5d6d4ba62156 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> 2016-11-23T14:24:00+00:00 Khem Raj raj.khem@gmail.com 2016-11-03T08:20:32+00:00 urn:sha1:8076afca3d5f3b099be7344e6339085f3796394a Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> 2016-06-08T12:55:29+00:00 Manuel Bachmann manuel.bachmann@iot.bzh 2016-06-05T15:50:29+00:00 urn:sha1:d60961764b69df2b47c5838cf8bcef8e01be90c9 When compiling llvm3.3 and including meta_oe_security_flags.inc: - on x86 (qemux86 e.g.), text relocation warnings appear ; - on x86-64 (qemux86-64 e.g.), linking fails with the following error message: "relocation R_X86_64_PC32 against undefined symbol [...] recompile with -fPIC" Add llvm3.3 to the overrides list, so that it builds correctly. Signed-off-by: Manuel Bachmann <manuel.bachmann@iot.bzh> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> 2015-04-24T13:11:25+00:00 Dmitry Eremin-Solenikov dmitry_eremin@mentor.com 2015-04-18T14:59:37+00:00 urn:sha1:43ece2557f2fe620568fc194cbd4403daa8dc00e Some of recipes produce errors if the distro has enabled usage of security_flags.inc file. Fix those errors (and QA warnings) by providing an additional include file that is require'd from conf/layer.conf. Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>