| Summary: | All versions of openssl, smbd, openssh, and tcl that use _dl_tls_get_addr_soft bail on a link error when I try to execute them. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | darkseer <darkseer> |
| Component: | [OLD] Library | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED INVALID | ||
| Severity: | major | CC: | robbat2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
darkseer
2009-04-04 13:54:01 UTC
After running strings on the 2.8 version I can confirm the symbols are not there. Well, probably they were there in glibc 2.6, but you overdid it with static linking - those symbols are private, after all. As I said on the forums, try revdep-rebuild first. (In reply to comment #2) > Well, probably they were there in glibc 2.6, > but you overdid it with static linking - > those symbols are private, after all. > > As I said on the forums, try revdep-rebuild first. > Revdep-rebuld was done and ran to completion without error. You mention static linking, I don't believe I have the static keyword in there, how would I detect overdoining it? What am I looking for? If all I have to do is readujust a flag i'd be happy. -Glenn If revdep-rebuild failed to find any problems, you'll have a painful upgrade ahead of you. Let's get some info from you first: - output of 'emerge -1pv glibc tcl' - output of 'ldd -r /usr/bin/tclsh' In any case, I do hope, neither portage/python nor gcc show the same error. Oh, and one more thing, it may be a bit late, but do you recall if your glibc 2.6 was built with nptl useflag ? (In reply to comment #5) > Oh, and one more thing, it may be a bit late, > but do you recall if your glibc 2.6 was built with nptl > useflag ? > ntpl was enabled. Otherwise, ill be able to provide the other info tomorrow as I can't ssh to the box at the moment :) thanks for helping ! (In reply to comment #4) > If revdep-rebuild failed to find any problems, you'll have > a painful upgrade ahead of you. > Let's get some info from you first: > - output of 'emerge -1pv glibc tcl' > - output of 'ldd -r /usr/bin/tclsh' > > In any case, I do hope, neither portage/python nor gcc > show the same error. > The following is the ldd -r output, the error occured twice during the ldd command, but does not occur on a binary that doesn't use this symbol: /usr/bin/tclsh: relocation error: /usr/lib64/libc.so.6: symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference. linux-vdso.so.1 => (0x00007fff901fe000) libtcl8.4.so => /usr/lib64/libtcl8.4.so (0x00007f1487caf000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f1487aab000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f1487890000) libm.so.6 => /usr/lib64/libm.so.6 (0x00007f148760f000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007f14872d0000) /lib64/ld-linux-x86-64.so.2 (0x00007f1487f7c000) relocation error: /usr/lib64/libc.so.6: symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference. The following is the emerge output: These are the packages that would be merged, in order: Calculating dependencies .... done! [ebuild R ] sys-libs/glibc-2.8_p20080602-r1 USE="(multilib) nls profile -debug -gd -glibc-omitfp (-hardened) (-selinux) -vanilla" 0 kB [ebuild R ] dev-lang/tcl-8.4.18 USE="threads -debug" 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB there should be no libc.so.6, nor any other glibc library, in your /usr/ tree. they all go in /. delete the extra crap. ok, this may not be a glibc bug. For some reason gcc thinks glibc is in /usr/lib instead of /lib. Actually not gcc but ld. BEFORE ANYOE ASKS, Ive only done stock installs of gcc from portage. I haven't touched the gcc ebuild in any way shape or form. Manually putting /lib or /lib64 in the library path does nothing. For example: ld foo.o or gcc foo.c produces: ld: cannot find -lc If I try to foce the issue ld -L/lib64 -L/lib -lc foo.o produces the error message: ld: cannot find -lc I've manually verified that libc exists. Any hints? You could post your `emerge --info' for starters. :) (In reply to comment #10) > You could post your `emerge --info' for starters. :) > sorry, takes a while to get console access. Below is the emerge --info.As a work aroud, do you think installing a binary versoin of gcc and then reemerging gcc may solve the problem. I'm not sure how the load path got screwed up, but may that fix it? Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.25-gentoo-r7 x86_64) ================================================================= System uname: Linux-2.6.25-gentoo-r7-x86_64-AMD_Phenom-tm-_9850_Quad-Core_Processor-with-glibc2.2.5 Timestamp of tree: Sat, 11 Apr 2009 04:45:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.7 dev-lang/python: 2.4.4-r13, 2.5.2-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -msse3 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -msse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo " LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.4.1/gentoo-portage" USE="3dnow 3dnowext X Xaw3d a52 aac aalib accessibility acl alsa amd64 apache2 async ati bacula-console bash-completion bcmath berkdb big-tables bogofilter bzip2 cairo calendar cddb cdparanoia cgi cli cluster cracklib crypt css cups curl curl-wrappers dbus dri dts dv dvb dvd dvdr dvdread dynagraph elf emacs encode esd exif extrafilters ffmpeg fftw filepicker firefox flac flatfile fortran ftp gdbm gif gmp gnutls gphoto2 gpm gs gstreamer gtk hal hash iconv imagemagick imap imlib iodbc ipod ipv6 isdnlog ithreads ivtv java jpeg jpeg2k kde kerberos keyring krb4 lapack latex lcd ldap live livecd logrotate lzo mad math matroska md5sum mhash midi mjpeg mmx mmxext mng mono mozilla mp2 mp3 mplayer mpm-worker mudflap multilib musepack musicbrainz mux mysql mysqli mythtv nas ncurses network nfs nis nls nntp nptl nptlonly nsplugin odbc offensive opengl openmp oss pam pcre pdf pdo perl png pppd profile python qt3support qt4 radio rar rdesktop readline reflection rtc ruby samba sasl scanner screensaver sdl server session sndfile snmp soap sockets socks5 spl sqlite srt sse ssl ssse3 svg sysfs syslog sysvipc tcltk tcpd tetex theora threads tiff tk tokenizer transcode truetype unicode usb v4l v4l2 vcd vhosts vim-syntax vm-goto vorbis webkit wifi wmf x264 xcb xcomposite xforms xine xinetd xls xml xmlreader xmlrpc xmlwriter xorg xosd xpm xprint xscreensaver xsl xulrunner xv xvid xvmc yaz zeroconf zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia vmware" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Please provide the output from these commands:
# ls -la {/usr,}/lib{,32,64}/libc.so.6
# equery b {/usr,}/lib{,32,64}/libc.so.6
so you screwed up your glibc install ? still not a toolchain bug. all glibc SONAMEs should be in /lib* while there are linker scripts placed in /usr/lib*. thus ld has no problem finding appropriate libs. if you cant recover your glibc mess, get a binpkg from someone (like tinderbox) (In reply to comment #13) > so you screwed up your glibc install ? still not a toolchain bug. all glibc > SONAMEs should be in /lib* while there are linker scripts placed in /usr/lib*. > thus ld has no problem finding appropriate libs. > > if you cant recover your glibc mess, get a binpkg from someone (like tinderbox) > In what way did I screw up the glibc intall? Did I set a use parameter wrong? Some other obscure paramater I'm not aware of? I certianly wasn't hand jamming glibc from the tarball. I have 2 goals here, I'm trying to find out what happened and I'm trying to fix it. During upgrade all I remember doing was was emerge -av world. Is there some way to find out how it all went horribly horribly wrong? So maybe it isn't a tool chain bug, but then what? If it is user error it's somthing I haven't run across in several years of gentoo usage. Not that this means I'm above making a stupid mistake, mostly I'm curious. If I wanted a quick fix, I have a backup partition on the system drive, I would have done a fresh install, re-emerged my packages, copied configs, and updated the boot loader to point to the new partition. However, I'm trying to find the root of the problem so at the very least I can warn people what not to do. darkseer: you still have not provided the output I asked for in comment #12. please reopen this bug once you have done so. (In reply to comment #15) > darkseer: > you still have not provided the output I asked for in comment #12. > please reopen this bug once you have done so. > It takes a while to get physical access since I can't ssh in. Here is the info: equery b output /usr/lib/libc.so.6 (null) /usr/lib64/libc.so.6 (null) /usr/lib32/libc.so.6 (null) /lib/libc.so.6 (null) /lib32/libc.so.6 sys-libs/glibc-2.8_p20080602-r1 /lib64/libc.so.6 sys-libs/glibc-2.8_p20080602-r1 ls output: lrwxrwxrwx 1 root root 13 Apr 6 17:36 /usr/lib/libc.so.6 -> libc-2.6.1.so lrwxrwxrwx 1 root root 13 Aug 28 2008 /usr/lib32/libc.so.6 -> libc-2.6.1.so lrwxrwxrwx 1 root root 13 Apr 6 17:36 /usr/lib64/libc.so.6 -> libc-2.6.1.so lrwxrwxrwx 1 root root 11 Apr 3 15:13 /lib/libc.so.6 -> libc-2.8.so lrwxrwxrwx 1 root root 11 Apr 3 15:13 /lib32/libc.so.6 -> libc-2.8.so lrwxrwxrwx 1 root root 11 Apr 3 15:13 /lib64/libc.so.6 -> libc-2.8.so That shows us you have a copy of libc on your system that is either orphaned or was never installed with Portage in the first place. So it's NOT a portage error.
If you've got Portage logs that show it creating the files, then you can reopen this, otherwise it's something you did to your own system.
As for fixing it, I suggest the following:
for i in /usr/lib/libc.so.6 /usr/lib32/libc.so.6 /usr/lib64/libc.so.6 /usr/lib/{libc-2.6.1.so,ld-linux.so,ld-2.6*.so,ld-linux-x86-64.so.2} ; do mv ${i} ${i}.disabled ; done ;
If it's a symlink to a copy in /lib, don't remove it. If it points to the bad copy of libc, then do rename/remove it.
(In reply to comment #17) > That shows us you have a copy of libc on your system that is either orphaned or > was never installed with Portage in the first place. So it's NOT a portage > error. > If you've got Portage logs that show it creating the files, then you can reopen > this, otherwise it's something you did to your own system. > > As for fixing it, I suggest the following: > for i in /usr/lib/libc.so.6 /usr/lib32/libc.so.6 /usr/lib64/libc.so.6 > /usr/lib/{libc-2.6.1.so,ld-linux.so,ld-2.6*.so,ld-linux-x86-64.so.2} ; do mv > ${i} ${i}.disabled ; done ; > > If it's a symlink to a copy in /lib, don't remove it. If it points to the bad > copy of libc, then do rename/remove it. > You are correct, it is not a portage error. I created binary packages of glibc and gcc on a similar machine and installed the new packages on problem machine. Then I verified that nothing bad was in /usr/lib. Viola, ssh, openssl, and wget all started working. However gcc is now complaining that ld con no longet find libc ( I can't compile an empty test program with no includes). I checked that I was pointing to the correct verion of gcc sing gcc-config -l. After I ran gcc-config -l ssh, openssl, and wget all stoped working. I verified that the thing responsible for putting libc where it shouldn't be was gcc-config. gcc-config thinks for some reason the /usr/lib is a cooler place to put and link to libc than /lib. I am hoping this is a configuration issue with gcc-config and I'm a revdep-rebuild away from happiness. My question is where do I look to point gcc config to the right place? I'm certain you've still got some badness in your system. Probably in gcc, but maybe somewhere else. 1. Go and find every non-symlink, non-directory entry in /usr/lib*/ and /lib*/ (not their subdirectories) 2. Check ALL of them against your /var/db/pkg. 3. Remove ALL of the ones that aren't in /var/db/pkg. 4. Find and remove ALL broken symlinks (find -L -type l) 5. Also check for files that SHOULD be in those directories, and are missing. (In reply to comment #19) > I'm certain you've still got some badness in your system. Probably in gcc, but > maybe somewhere else. > > 1. Go and find every non-symlink, non-directory entry in /usr/lib*/ and /lib*/ > (not their subdirectories) > 2. Check ALL of them against your /var/db/pkg. > 3. Remove ALL of the ones that aren't in /var/db/pkg. > 4. Find and remove ALL broken symlinks (find -L -type l) > 5. Also check for files that SHOULD be in those directories, and are missing. > I kinda agree with the resolved/invalid status, whatever the issue is I'm sure it is not as stated in the title. Should we keep the discussion in the fourm at http://forums.gentoo.org/viewtopic-t-752600.html and close this out? |
