Summary: | gcc/files/scan_libgcc_linked_ssp.sh stops after first match | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Scott Taylor (RETIRED) <swtaylor> |
Component: | New packages | Assignee: | Please assign to toolchain <gcc-porting> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | amd64, ia64, solar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Scott Taylor (RETIRED)
2004-01-07 12:00:24 UTC
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? |