| Summary: | sys-libs/glibc-2.10+ no longer exports __guard for old ssp (gcc-3.x) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nico Baggus <mlspamcb> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | andreas.thalhammer, arjenjb, glynn, hkmaly, jer, jlamanna, sandino |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nico Baggus
2010-01-14 02:05:38 UTC
emerge --info yields:
!!! Failed to complete python imports. These are internal modules for
!!! python and failure here indicates that you have a problem with python
!!! itself and thus portage is not able to continue processing.
!!! You might consider starting python with verbose flags to see what has
!!! gone wrong. Here is the information we got for this exception:
/lib/libz.so.1: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference
!!! Failed to complete python imports. These are internal modules for
!!! python and failure here indicates that you have a problem with python
!!! itself and thus portage is not able to continue processing.
!!! You might consider starting python with verbose flags to see what has
!!! gone wrong. Here is the information we got for this exception:
/lib/libz.so.1: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference
some advise to get back to a working system is also welcome You could get your /etc/make.conf off the system and attach it here. And you could at least list the target of the /etc/make.profile symlink you use there. It's probably best to reboot into something bootable and then replace the glibc package using an autobuild tbz2 that you download from [1]. [1] http://tinderbox.dev.gentoo.org/ The system has been emerged a week ago,
revdep rebuild has also been run after that. So the system was fairly clean before starting this emerge.
make.profile:
lrwxrwxrwx 1 root root 57 Sep 27 19:00 /etc/make.profile -> ..//usr/portage/profiles/default/linux/amd64/10.0/desktop
Make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
CFLAGS="-O2 -pipe -mno-tls-direct-seg-refs -g -Wl,--as-needed"
CXXFLAGS="${CFLAGS}"
# This should not be changed unless you know exactly what you are doing. You
# should probably be using a different stage, instead.
CHOST="x86_64-pc-linux-gnu"
MAKEOPTS="-j3"
# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="PUEL sun-bcla-java-vm dlj-1.1"
USE=" -apm -gnome -oss -eds -arts sse sse2 mmx pic
X
a52 aac aalib acl accessibility acpi activefilter ads aio akode alsa ao apache2 aqua audiofile audit authdaemond automount avahi
bash-completion bl bluetooth bookmarks bzip2
cairo caps cdda cddb cdparanoia cdr cgi chm cleartype clvm cman cscope css curl
dbus dga directfb dts dv dvb dvd dvdr
eap-tls encode esd exif exiscan exiscan-acl expat
fam fame fastcgi fax fbcon ffmpeg flac fltk foomaticdb fpx frxp
gd ggi gif gimp glib gmp gnokii gnutls gphoto2 graphviz gs gsm gstreamer gtk guile
hal howl-compat hpn html http httpd
ical icecast idn id3 id3tag ieee1394 ilbc imap imlib ipv6 ithreads irda
jabber jack java javascript jbig jingle jpeg jpeg2k joystick justify
kde kdeprefix kerberos kipi kqemu
ladspa lame laptop lcms ldap libcaca libsamplerate live lm_sensors lmtp loop-aes lua lzma lzo
mad mailwrapper matroska mbrola md5sum mdnsresponder-compat memcache mhash mikmod mjpeg mmap mng motif mp2 mp3 mp4 mpeg mplayer musepack musicbrainz mysql
nagios-dns nagios-game nagios-ntp nagios-ping nagios-ssh nas netboot network nls nptl nsplugin nvidia
obex odbc odk ogg openal openexr opengl oscar oss
pda pdf php plotutils png pnm portaudio postscript ppds pth pulseaudio
qt3 qt3support quicktime quotas
radius rar rdesktop real rle rrdtool rtc ruby
samba sasl scanner sdl server skey slang sndfile snmp span speex spell spf sqlite sqlite3 srs ssl subversion svg svga swat symlink sysfs syslog
theora threads tiff timidity tools truetype tta
unicode ups urandom usb utempter
v4l v4l2 vcd vde vidix vim-syntax vnc vorbis
wavpack webdav wifi win32codecs winbind wma wmf
x264 xanim xattr xfs xine xml xmlreader xmlrpc xmlwriter xosd xpm xscreensaver xv xvid xvmc
yaz yv12
zeroconf zip zrtp "
ALSA_CARDS="hda-intel usb-audio"
VIDEO_CARDS="nvidia nv via vesa vga fbdev"
INPUT_DEVICES="evdev keyboard mouse synaptics joystick"
CAMERAS="ptp2 canon casio"
LINGUAS="en_GB en_US nl_NL nl en"
APACHE2_MPMS="peruser" #One of: event itk peruser prefork worker
FEATURES="parallel-fetch userpriv sandbox usersandbox"
#GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mir.zyrianes.net/gentoo/"
GENTOO_MIRRORS="ftp://212.219.56.134/sites/www.ibiblio.org/gentoo/ http://mirror.cambrium.nl/pub/os/linux/gentoo/ http://ftp.twaren.net/Linux/Gentoo/"
PORTDIR_OVERLAY=/usr/local/portage
# This sets what to log
PORTAGE_ELOG_CLASSES="warn error log info qa"
# And this is how to do it
PORTAGE_ELOG_SYSTEM="save jabber"
#Specify the sender jabber account:
PORTAGE_ELOG_JABBERFROM="host.chippie@baggus.net:chippiehost"
#Specify a list of receivers:
PORTAGE_ELOG_JABBERTO="admin@baggus.net nico@baggus.net"
PORTAGE_ELOG_JABBERCHAT=" " #emerge-reports@muc.baggus.net/chippie"
PORTAGE_ELOG_SUBJECT='${PACKAGE} on ${HOST}'
#
PORT_LOGDIR=/var/log/portage
PORTAGE_TMPFS="/dev/shm"
#CONFIG_PROTECT_MASK="/etc/portage"
#SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage"
source /usr/local/portage/layman/make.conf
__guard is only needed if your system is horribly out of date. i dont plan on re-adding the old ssp symbols to glibc. so to fix your system, grab a tbz2 of a glibc-2.9 version, and then re-emerge all the packages that still refer to __guard. So some programs & labraries are linked against an old glibc? maybe glibc for 64bit was adopted to old.... anyway HOW to test for this condition? I tend to agree that old symbols don't need to be reintroduced, at least not Bork a regularly updated system (emerge --sync, emerge -1vauDN world , revdep-rebuild and an occasional emerge -p --depclean) Appearantly this is "somewhat easy" to prevent.... (the only thing is to known HOW to do it...) grep for __guard om executables & libraries. maybe a test in revdep-rebuild? really dont know what you mean about glibc and 64bit. __guard really has nothing to do with the host architecture. use scanelf to locate broken binaries: scanelf -qRs__guard /bin/ /lib/ also, i lied ... we still support the old __guard compat symbol, but only on hardened profiles. not that you should have had references to __guard in the first place when using a non-hardened profile. perhaps you switched on the fly. I think that there was some period between the stabilisation of various glibc libraries, amd64 trails in that aspect. Clearly some time ago it the __guard became irrelevant, but somehow on x86 this was already fixed .... f.e. libacl on a x86 was last compiled aug. 18 2008 appearantly then __guard was already gone, the laptop has been setup a little later with amd64 as platform dec 2008 so even then __guard was actually needed then... in that aspect amd64 is different from x86... If needed I can provide an emerge log for the record these are the problematic programs... -rwxr-xr-x 1 root root 76120 Sep 7 2008 /bin/gzip -rwxr-xr-x 1 root root 116888 Sep 8 2008 /bin/mail -rwxr-xr-x 1 root root 412576 Sep 7 2008 /bin/tar -rwxr-xr-x 1 root root 34504 Sep 8 2008 /lib/libdm.so.0.0.4 -rwxr-xr-x 1 root root 51160 Aug 31 2008 /lib/libsysfs.so.2.0.1 -rwxr-xr-x 1 root root 39648 Sep 1 2008 /lib/libwrap.so.0.7.6 -rwxr-xr-x 1 root root 87936 Mar 14 2008 /lib/libz.so.1.2.3 -r-xr-xr-x 1 root root 18392 Aug 31 2008 /sbin/paxctl -rwxr-xr-x 1 root root 22656 Aug 31 2008 /sbin/portmap -rwxr-xr-x 1 root root 287552 Sep 8 2008 /sbin/xfsdump -rwxr-xr-x 1 root root 324768 Sep 8 2008 /sbin/xfsrestore -rwxr-xr-x 1 root root 262416 Sep 8 2008 /usr/sbin/atmsigd -rwxr-xr-x 1 root root 127080 Sep 10 2008 /usr/bin/ltrace -rwxr-xr-x 1 root root 320704 Sep 11 2008 /usr/bin/rateup -rwxr-xr-x 1 root root 811104 Sep 11 2008 /usr/bin/silc -rwxr-xr-x 1 root root 1549392 Sep 12 2008 /usr/lib/opensync-1.0/plugins/python-module.so -rwxr-xr-x 1 root root 31176 Oct 29 2008 /usr/bin/rle2gif -rwxr-xr-x 1 root root 22920 Oct 29 2008 /usr/bin/gif2rle -rwxr-xr-x 1 root root 4835904 Apr 16 2009 /usr/bin/fwbuilder -rwxr-xr-x 1 root root 31176 Sep 30 22:39 /usr/bin/rletopnm -rwxr-xr-x 1 root root 35368 Sep 30 22:39 /usr/bin/pnmtorle ----------------------- scanelf shows about 241 hits in /bin, /lib, /sbin, /usr/bin, /usr/lib, /usr/sbin ----------------------- match from tbz2 -rwxr-xr-x 1 root root 119064 Jun 29 2009 /lib/ld-2.9.so -rwxr-xr-x 1 root root 1334448 Jun 29 2009 /lib/libc-2.9.so whether __guard refs made it into your binaries doesnt matter on the arch. the default profiles (i.e. non-hardened) have never forced ssp into things. you either were using SSP flags manually, or you were using the hardened profile and then you switched away w/out rebuilding things. i cant think of any scenario otherwise. *** Bug 300808 has been marked as a duplicate of this bug. *** hm yes hardened was attempted once, it didn't actually work out and I undid it. It was followed by an 'emerge -e world' ... that should have teken care of it I guessed, appearantly it didn't exactly work out that way it now appears. the trouble is that you would have had to re-emerge gcc first and make sure the spec settings in your profile/env were reverted to vanilla. if they werent, then an -e world wouldnt have fixed everything. if i get more reports of this issue biting people, then i can add a sanity check before emerging things ... but i'd prefer not to of course ... The sanity in my system is back to normal. One thing to keep in mind also is to explicitly check /lib64 & /lib32 differently if affected. because /lib is not found to get back to installable ebuild names. I doubt i'm the only one with problems because I gave up on hardened after too much shit hit the proverbial fan. My intent was to get a tamper resistant laptop. Using encrypted partition/volumes should do it for now. use scanelf to find libraries having the __guard symbol scanelf -qRs__guard /lib64 /usr/lib64 (for 64 bit) scanelf -qRs__guard /lib /usr/lib (for 32 bit) This gives a list of files: /bin/gzip /bin/mail /bin/tar /lib64/libdm.so.0.0.4 /lib64/libsysfs.so.2.0.1 using epm you can find the packages that produced the files (mind the /lib64 for 64bit...) epm -qGf /bin/mail epm -qGf /bin/tar epm -qGf /lib64/libdm.so.0.0.4 epm -qGf /lib64/libsysfs.so.2.0.1 ... giving you the package names like f.e. mail-client/mailx-8.1.2.20050715-r1 sys-apps/dmapi-2.2.8 ... Which can be emerged. Before emerging various packages BE SURE to block the glibc update (temporarily as a masked packages using /etc/portage/package.mask) After all old pains have been fixed you can remove the glibc package.mask. Then apply all updates again. *** Bug 302341 has been marked as a duplicate of this bug. *** You can use the fix in Bug 125988 ------- Comment #14 From SpanKY 2006-03-16 20:34:35 0000 [reply] ------- ok, glibc-2.4-r1 should resolve this if you guys have a broken system and are unable to sync/re-emerge glibc, then you can grab prebuilt lib's to work around this issue: # bb # wget http://dev.gentoo.org/~vapier/amd64_libssp_simple.so # mv amd64_libssp_simple.so /lib/libssp_simple.so # echo /lib/libssp_simple.so > /etc/ld.so.preload for x86 users, just change the "amd64" to "x86" once you've installed glibc-2.4-r1, then just delete /lib/libssp_simple.so and /etc/ld.so.preload and you should be all set thanks to solar for this little hack workaround *** Bug 320063 has been marked as a duplicate of this bug. *** Do I understand correctly that switching to hardened profile for compiling glibc will protect me against this bug? (Please do NOT answer like "to switch to hardened profile you need to recompile world". I obviously won't and I still didn't find clear documentation explaining why just setting "hardened" use flag to have hardened toolchain is not possible anymore). If support for __guard will be dropped even for hardened profiles, can you tell when? |
