It is certainly a much prettier version, but having to restart it after finding only one package to update, updating that, running it again... At least the good old scripts from before yielded a whole list of packages to update. It is one thing to break out of the gcc ebuild after the first one, but when I run the script at the command line to find all the affected packages, I expect to see them. __guard at GCC check in: /usr/bin/indxbib sys-apps/groff * 102: 00000000 32 OBJECT GLOBAL DEFAULT UND __guard@GCC_3.0 (4) -- __guard at GCC check in: /usr/bin/swig dev-lang/swig * 146: 00000000 32 OBJECT GLOBAL DEFAULT UND __guard@GCC_3.0 (5) -- __guard at GCC check in: /usr/bin/python2.3 dev-lang/python * 42: 00000000 32 OBJECT GLOBAL DEFAULT UND __guard@GCC_3.0 (2) (and then some) X files # ./scan_libgcc_linked_ssp.sh * Scanning system for __guard@GCC symbols... * Scanning 01 of 14 /lib... * Scanning 02 of 14 /usr/lib... * Scanning 03 of 14 /opt/blackdown-jdk-1.4.1/jre/lib/i386... * Scanning 04 of 14 /usr/local/lib... * Scanning 05 of 14 /bin... * Scanning 06 of 14 /opt/bin... * Scanning 07 of 14 /opt/blackdown-jdk-1.4.1/bin... * Scanning 08 of 14 /opt/blackdown-jdk-1.4.1/jre/bin... * Scanning 09 of 14 /sbin... * Scanning 10 of 14 /usr/bin... * Found __guard@GCC_3.0 in /usr/bin/eqn! * Please emerge '>=sys-apps/groff-1.18.1-r4' X files #
Yes we want it like that so we don't waste the users time continuing to scan over and over. You can manually rerun the script from command line via awk -f /usr/portage/sys-devel/gcc/files/awk/scanforssp.awk And keep remerging till the list becomes empty. If it yaps about python2.2 and you have rebuilt python and it becomes a python2.3 install then you just have to move the /usr/bin/python2.2 out of the way and continue the build. I suggest this bug be marked as INVALID
I go for this as well. Solar, what do you think about the SSP stuff in -r7? Can we move it to -r5, as it will save the user the unpack, etc?
Martin, I've not built the gcc yet but what I notice first is that it has a special hook for amd64 and it's libc.so.6 when I do diff -u gcc-3.3.2-r{5,7} Was this planned? I thought thus far it was only the ia64 that had the libc.so.6.1 When I rm /etc/env.d/*spp* /etc/env.d/*ssp* ebuild gcc-3.3.2-r7.ebuild clean unpack I can't seem to get the awk script to run no matter what. (is this expected?)
Did you also unset GLIBC_SSP_CHECKED in the shell you were trying to merge it? Got me the first time as well ... As for the hook ... I did mail you a few times to have a look, but seems you missed it. For amd64 we can thus then just change the ? to 6, as it should really be lib64. I really just added the ? because I needed an example, and the lib64 change needed doing anyhow ... What is the full path on ia64?
Mails sent you. To: Martin Schlemmer <azarah@gentoo.org> Cc: Gentoo-Base-System <base-system@gentoo.org> Subject: Re: gcc-3.3.2-r[456] Date: 03,04 Feb 2004 ---------------------------------------------------- It's ok I think we might miss little snippets from mail from each other from time to time. Anyway what I did was log into ia64, amd64, sparc64, ppc, ia32 running mostly stable tool chains on all. I found libc to be at the following location on those arches with the exception being the ia64 which has the libc shared object in the /lib/libc.so.6.1 so what came to mind was to append .1 to an already defined libcso variable. Something like this. LIBCSO="/lib/libc.so.6" [ "$ARCH" = "ia64" ] && LIBCSO="${LIBCSO}.1" syntax does not matter the existing 'case' is fine, just thought the amd64 might have been mixed up with the ia64. I don't know anything about the /libc64/ dir and unfortunately cant check on those arches again till I get some broken key magic or other problem straitened out. ------- As for the environment variable. ding, ding. Thanks you hit the nail on the head. Now the fun can begin. I'm rebuilding gcc now, then will rebuild it again (with a more carefull note to the env) and report back results.
solar $ env | grep SSP GLIBC_SSP_CHECKED=1 [ebuild R ] sys-devel/gcc-3.3.2-r7 +X -bootstrap -build -java -multilib +nls -static 0 kB >>> md5 src_uri ;-) gcc-3.3.2-manpages.tar.bz2 >>> Unpacking source... >>> Unpacking gcc-3.3.2.tar.bz2 to /var/tmp/portage/gcc-3.3.2-r7/work No SSP check preformed the second time.. dies on first match if symbol is found. It can can rebuild itself.. Wins my vote.
I remember your mail, and that is why I changed it (I sent my mails after yours ...), but I forgot which arch and glibc =). Maybe the amd64/ia64/ppc64 teams can point to what their glibc symlinks is?
