glibc-2.3.2-r9 causes several programs to not compile when using the hardened-gcc specs. Find here a sample output of a broken vim build: http://dev.gentoo.org/~zhen/fail.txt vim emerges fine on a default install (default profile, no hgcc) using glibc-2.3.2-r9.
I dont know if I can fix this one but I'll look into it. First test rebuild vim with existing glibc-r3 [ebuild R ] app-editors/vim-6.2-r5 -ncurses +nls -acl -cscope -gpm +perl +python -ruby -vim-with-x -minimal # works emerge sync emrege -pv glibc [ebuild U ] sys-libs/glibc-2.3.2-r9 [2.3.2-r3] +nls +pic -build testing this now. I'll build this glibc then try to build vim again, then I'll report back results here.
zhen What are the several problems (outside of vim) ?
Sorry, I thought that lilo was experiencing similar problems, but I found that it builds fine in the current stages. vim is the only problem package that I have seen so far.
Ack the box hard locked.. pappy can you peek this one please as I know you actually like vim and all.
Ok, it appears the the dl_exec patch is the problem. I edited the glibc-2.3.2-r9 ebuild and commented out line 292 (the patch addition line), rebuilt glibc, and then successfully rebuilt vim. The lines that I edited: original: # This is due to PaX 'exec-protecting' the stack, and ld.so then trying # to make the stack executable due to some libraries not containing the # PT_GNU_STACK section. Bug #32960. <azarah@gentoo.org> (12 Nov 2003). epatch ${FILESDIR}/2.3.2/${PN}-2.3.2-dl_execstack-PaX-support.patch changed: # This is due to PaX 'exec-protecting' the stack, and ld.so then trying # to make the stack executable due to some libraries not containing the # PT_GNU_STACK section. Bug #32960. <azarah@gentoo.org> (12 Nov 2003). #epatch ${FILESDIR}/2.3.2/${PN}-2.3.2-dl_execstack-PaX-support.patch
This is not good at all. If we remove that patch then we may run into other problems. What I dont quite understand is how that patch could cause any problems for vim or otherwise. All it does is adds an extra hook to glibc to deal with errno return values from the kernel. http://bugs.gentoo.org/attachment.cgi?id=20445&action=view And the problem you were encounterting seemed to be with a vim macro thinking the sizeof int was 0. Azarah any ideas?
Could we get that auto/config.log for the failed build in here?
any idea where that would be? I am in /var/tmp/portage/vim-6.2-r5/work and do not see any logs for configure, etc
zhen, either do a find /var/tmp/portage/vim-6.2-r5/work -name '*log' or post the whole darn dir. We only have a few more days to get this all fixed.
http://dev.gentoo.org/~zhen/Hardened/vim/vim62/src/auto/config.log Found it - sorry for the delay. The topmost directory there contains the image from /var/tmp/portage/${P}/work
This is the test that fails. #include <stdio.h> main() { FILE *f = fopen("conftestval", "w"); if (!f) exit(1); fprintf(f, "%d\n", (int) sizeof(int)); exit(0); } // something to do with.. # if (SIZEOF_INT == 0) Error: configure did not run properly. Check auto/config.log. # endif // and this is bad code to begin with btw should use #error blah blah // Note the # So, there're two options 1. take out make_stack_executable() altogether from glibc. (PaX preference) 2. keep it but then you must keep the extra patch as well I'm building this in a chroot to see if we have other options and to make sure I can reproduce it but this all just sounds screwy.. I sure hope this is not a PEBKAC.
Right, I checked what test it was, but I thought I could see some more from the log ...
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -mcpu=i686 -fomit-frame-pointer -DPERL5 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.0/i386-linux/CORE -I/usr/include/python2.2 -pthread -o objects/buffer.o buffer.c dies there.. Works fine from command line if we clean rm auto/config.{status,cache,h} ; ./configure ; make SIZEOF_INT will be properly defined 4 in auto/. It' links and everything and everything as a proper shared executable object. But it's getting SIZEOF_INT 0 from the ebuild. Like we can hack/sed our way around this but it's not very proper. zhen, I don't like this bug here, not one bit :)
I/we are going to need some more eyes to take a closer look here.
Is this still an issue? I had this on a fresh install, and it was due to the test program being linked to libtermcap, but the linker not finding it when it was run (test prog prints the size of int ...). After an ldconfig it worked just fine. I wonder if its not due ot env-update's new 'smart' ldconfig running ...
this is a duplicated bug and you should make sure to gcc -dumpspecs > $(gcc-config -L)/specs before going any further. if this bug is still apparent, please remove hardened-gcc and dump restore the specs. as previously noted, hardened-gcc will be replaced by a hardened gcc. thanks, Alex
*** Bug 43673 has been marked as a duplicate of this bug. ***
