On Oct 25, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote: > cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool > --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -DNEON_ZLIB > -rpath /usr/local/lib -o libsvn_subr-1.la auth.lo cmdline.lo config.lo > config_auth.lo config_file.lo config_win.lo ctype.lo date.lo error.lo hash.lo > io.lo lock.lo md5.lo opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo > subst.lo svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo > validate.lo version.lo xml.lo > /gcc/gcc/subversion-1.2.3/apr-util/libaprutil-0.la -lgdbm -ldb-4.2 -lexpat > /gcc/gcc/subversion-1.2.3/apr/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread > -ldl > /usr/lib/libgdbm.so: could not read symbols: Invalid operation > collect2: ld returned 1 exit status
> The problem is that /usr/lib/libgdbm is a 32-bit file. It should be using > /usr/lib64 and ld should know that. But it looks like something is > short-circuiting stuff. Does anybody know enough about svn build > procedures to know how to fix this? Libtool searches /usr/lib instead of /usr/lib64 because the Debian folks decided to not follow the AMD64 ABI, and libtool remained neutral in this regard (i.e., broken for both Debian and ABI-compliant distros). Try adding -L/usr/lib64 or something along these lines to LDFLAGS, so that libtool finds libs in the right place, and it should work. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
