As I have said, ipcop compile mostly LFS dev current (except gcc-4.4,
linux-2.6.32) with some hardening options :
glibc hardening
CFLAGS="-Os -march=${MACHINE} -mtune=pentium -pipe -fomit-frame-pointer -D_F
ORTIFY_SOURCE=2 -fstack-protector-all -fPIE -Wl,-z,now"
LDFLAGS="-Wl,--hash-style=gnu"There is still some TEXTREL in code but we live with that actually. Except when I try the compilation from a centos-5.5 box whre new problem happen. On this machine, I compile the 32-bits chapter05 without issue, but to my surprise, it fail on zlib-1.2.5 tests with ./minigzipsh: error while loading shared libraries: /usr/src/zlib-1.2.5/libz.so.1: cannot restore segment prot after reloc: Permission denied I understand this is a selinux error related to a TEXTREL on the shared lib : no problem. But what is out of my mind is why on this box compilation of zlib shared lib produce a TEXTREL but not on other build machines? I checked there is no TEXTREL for this lib on the other machines (scanelf -qtR is my friend). What could change gcc behavior? I have packaged the toolchain compiled on a box where it does not produce TEXTREL for zlib and untared on the centos box and restarted entire chap6 compilation. That does not change zlib TEXTREL issue. I checked chap6 glibc log and I spot only one difference in configure -checking whether ranlib is necessary... yes +checking whether ranlib is necessary... no If I remove -fPIE from our CFLAGS during zlib compilation, the TEXTREL disappear and test pass. But why is same gcc producing a different code inside the compilation chroot depending of the running machine? What could do that? Gilles -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
