cvs (1.11.20, default) emerged just fine (--info below), but running cvs now produces: cvs: symbol lookup error: cvs: undefined symbol: crypt arguments don't make any difference. Reproducible: Always Steps to Reproduce: 1.run cvs (any command; even just typing cvs and hitting enter produces this error, rather than a usage message) Actual Results: see "Detail" section, bove. Expected Results: I expect CVS to run. Portage 2.0.51.19 (default-linux/ppc64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 ppc64) ================================================================= System uname: 2.6.11-gentoo-r6 ppc64 PPC970FX, altivec supported Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, May 1 2005, 23:22:55)] dev-lang/python: 2.3.4-r1 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.9.4 sys-devel/binutils: 2.15.90.0.3-r4 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="ppc64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://adelie.polymtl.ca/ ftp://cs.ubishops.ca/pub/gentoo ftp://gentoo.risq.qc.ca/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X alsa apache2 arts berkdb bitmap-fonts cdr crypt cups curl dvd encode ethereal fam fortran gif gpm hardened imap jabber jack java jpeg kde ladcca mad motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam perl png postgres ppc64 python qt readline samba session sox speex spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts unicode usb vorbis wifi xine xml2 xv zlib userland_GNU kernel_linux libc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
please provide the output from: ldd `which cvs` nm /lib/libcrypt.so.1 | grep crypt I really don't know how you broke your system libs (libcrypt is provided by glibc).
<g> I don't know how I broke them either... I don't think I've done anything particularly interesting. Are there common ways to wind up in such a predicament? --pretend said: [ebuild R ] sys-libs/glibc-2.3.4.20041102-r1 I re-emerged glibc, successfully. Before doing so, the output you asked for looked like this: # ldd `which cvs` libnsl.so.1 => /lib/libnsl.so.1 (0x0000008000033000) libc.so.6 => /lib/libc.so.6 (0x0000008000059000) /lib64/ld64.so.1 (0x0000008000000000) # nm /lib/libcrypt.so.1 | grep crypt nm: /lib/libcrypt.so.1: no symbols But only nominally different after: # ldd `which cvs` libnsl.so.1 => /lib/libnsl.so.1 (0x0000008000033000) libc.so.6 => /lib/libc.so.6 (0x000000800005a000) /lib64/ld64.so.1 (0x0000008000000000) # nm /lib/libcrypt.so.1 | grep crypt nm: /lib/libcrypt.so.1: no symbols
did it work after you merged glibc again? My CVS (on ~x86) is linked against a lot more stuff: x29 / # ldd `which cvs` linux-gate.so.1 => (0xffffe000) librt.so.1 => /lib/tls/librt.so.1 (0xb7fc4000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7f95000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7f7f000) libz.so.1 => /lib/libz.so.1 (0x419a8000) libpam.so.0 => /lib/libpam.so.0 (0xb7f77000) libc.so.6 => /lib/tls/libc.so.6 (0xb7e4a000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7e37000) /lib/ld-linux.so.2 (0xb7fea000) libdl.so.2 => /lib/libdl.so.2 (0xb7e32000)
Don't use nm. It's not very effetive in case the of stripping. Use rather. readelf -s /lib/libcrypt.so.1 | grep [' ','\t']crypt glibc should provide the symbol.
I believe this and a couple of other problems I've been having are related to my 'hardened' USE flag -- I've now removed that flag and am trying to rebuild gcc/glibc/etc., but am getting segfaults upon compilations. And I just rebooted for the first time since I started this effort and the kernel crashed. So I'm in a bit of a hosed state that I'll be trying to work my way out of and then I'll report back, hopefully with something useful for closing this bug out one way or another.
I've resolved this bug by un-hardening my machine. Shall we mark it resolved and/or completely pass on to the hardened team?
hardened: user has found this bug went away after he un-hardened his machine, ergo I suspect the problem lies in your court.
Sure I'll take this one with dostrow who said he would confirm this later tonite.
any update on this one?
Sorry no.. dostrow and myself have not had a chance to work much together on ppc64 support.
hardened: *bump* is the problem still present, or can this bug be closed?
hardened? Comments?
Just tested and yes this is still a problem. tested from a vanilla ppc64 and simply switched to some hardened specs. power5 / # gcc-config -l [1] powerpc64-unknown-linux-gnu-3.4.4 [2] powerpc64-unknown-linux-gnu-3.4.4-hardened * [3] powerpc64-unknown-linux-gnu-3.4.4-hardenednopie [4] powerpc64-unknown-linux-gnu-3.4.4-hardenednopiessp [5] powerpc64-unknown-linux-gnu-3.4.4-hardenednossp [6] powerpc64-unknown-linux-gnu-4.1.1 power5 / # env USE=crypt emerge cvs .. power5 / # cvs cvs: symbol lookup error: cvs: undefined symbol: crypt power5 / # scanelf -Bn `which cvs` ET_DYN libnsl.so.1,libz.so.1,libpam.so.0,libc.so.6 /usr/bin/cvs power5 / # qlist -Uv cvs dev-util/cvs-1.12.12-r2 (crypt pam) And of course. power5 / # LD_PRELOAD=/lib/libcrypt.so.1 cvs Usage: cvs [cvs-options] command [command-options-and-arguments] --- The fix is simple. inherit flag-o-matic .. src_compile() { ... use crypt && apppend-ldflags -lcrypt .. }
When built vanilla on ppc64, does the executable have the entry for libcrypt? I'm assuming it's failing on hardened due to BIND_NOW (forcing all symbol references to be resolved at load time). If this is the case, then the vanilla version has unresolvable references that would probably segfault if the code path that uses them is taken. What does the configure phase (config.log et. al.) show? (why is it failing to locate and include lcrypt?)
Non hardened compiler thats gcc-4.1.1 based results in power5 / # scanelf -Bn `which cvs` ET_EXEC librt.so.1,libcrypt.so.1,libnsl.so.1,libz.so.1,libpam.so.0,libc.so.6 /usr/bin/cvs Then switching back to gcc-3.x-hardened.specs ./configure --stuff ... ... checking for library containing crypt... none required This is probably due to symbol visibility in pic objects.
config.log should show why it thinks it doesn't need the library - it tries to build a simple program that uses crypt, which should fail to link; e.g.: configure:36691: checking for library containing crypt configure:36721: i686-pc-linux-gnu-gcc -o conftest -O2 -pipe conftest.c -lresolv -lcom_err -lnsl >&5 /data/g2/tmp/portage/dev-util/cvs-1.12.12-r2/temp/ccSnLZfL.o: In function `main': /data/g2/tmp/portage/dev-util/cvs-1.12.12-r2/work/cvs-1.12.12/conftest.c:258: undefined reference to `crypt' collect2: ld returned 1 exit status configure:36727: $? = 1 configure: failed program was: ... It'd be useful to know what's in config.log for the case where the test decides libcrypt is not required (i.e. gcc-3 - hmm; I take it that the configure check is ok when using gcc-3 vanilla?). There's a comment in the configure script that suggests there's a built-in crypt() in gcc2 that it has to explicitly avoid - so perhaps there's something similar happening.
Yeah maybe. but the solution in comment #15 simply works.
comment #13 rather.. inherit flag-o-matic .. src_compile() { ... use crypt && append-ldflags -lcrypt ..
Certainly :) I'm worrying about the more general case - if the configure check (which comes from simple use of the standard AC_SEARCH_LIBS macro) isn't working right in this particular case, maybe it also fails elsewhere.
Oh it for sure fails elsewhere. This has been a long standing problem from nearly hardened day 0x03..
this is a hardened bug, not a ppc64 one.
This appears to be fixed, no comments in almost 2 years. Reopen if problem still persists.
