On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote: > On Fri, 2017-06-09 at 13:24 +0000, Khem Raj wrote: > > > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <[email protected]> > > wrote: > > > > On Wed, 2017-06-07 at 21:44 +0000, Peter Kjellerstedt wrote: > > > My guess is that the problem stems from the fact that > > security_flags.inc > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather > > than > > > SECURITY_LDFLAGS... > > > > I think I've seen that cause problems elsewhere when the > > CFLAGS came > > after -shared, because then the compiler ended up trying to > > produce a > > pie executable instead of a shared library. > > > > Perhaps we should finally address that in security_flags.inc > > instead of > > working around it? > > > > > > This patch is removing -pie from compiler and linker flags which does > > not result in intended behavior for executable when linked they will > > not be using -pie > > The patch had some syntax errors (fixed version below), but it had the > code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so > conceptually the flag shouldn't get lost entirely. > > Are you saying that one cannot rely on TARGET_LDFLAGS being used during > linking? > > I've tested with m4, and it seems to work okay: > > $ grep -w -e -pie > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile > x86_64-refkit-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse > -msse4.2 > --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot > -O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0 > > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native= > > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot= > -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat > -Wformat-security -Werror=format-security -Wl,-O1 -Wl,--hash-style=gnu > -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 m4.o > builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o > symtab.o ../lib/libm4.a > > $ file > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4 > > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4: > ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, > BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped > > I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB > executable" means "pie executable"?
While I don't think my patch caused -pie to get lost, unfortunately I now know that it still doesn't go into the right place in all cases. For example, ncurses puts LDFLAGS after -shared, thus triggering the "main undefined" error. The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after the command, so that seems like a better place for -pie than LDFLAGS. It's still a bit odd to pass a linker flag to all compiler invocations, including those that do not link, but it might be a pragmatic solution that is better than what we have now. However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be built for gcc-runtime, which triggers an error: ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/lib/libstdc++.a-gdb.py That file is not present at all without the patch. If anyone has a clue about what might be causing that, I'm all ears... -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
