Subversion 1.2.3 Libtool Linking Fails under Fedora Core 4

I've been attempting to resolve this Subversion 1.2.3 linking issue
offline for
a couple of days under Fedora Core 4 but to know avail. Time to turn to the list.

I have to date been unsuccessful building Subversion 1.2.3 on my Fedora Core 4
box since upgrading to Core 4 about 1 month ago. I have not used Subversion on
this new box to date, but wish to prepare it for the day I need it. I've been
using subversion for a number of years and this is the first time I had trouble
building it either on Solaris or Redhat/Fedora based Linux variants.

My problem is the build fails to link svnadmin.

The problem is strikingly similar to the one describe for Solaris 10 and I
attempted the suggestions outline here and in other places.

http://nixdoc.net/files/forum/about46431.html

In sum:
- Upgraded GCC 4.0.0 to 4.0.1-4 (and more recently 4.0.1-5 as an RPM from Redhat
updates), principally to get Umbrello working, but talk around the web suggests
4.0.0 has various issues.

- Upgraded glibc from core distribution revision to glibc-2.3.5-10.3 in the hope
that some problem (unknown to me) with libdl may have been fixed.

- Upgraded ld by replacing the Core 4 binutils from 2.15.x to 2.16.91 (built
from CVS source under gcc 4.0.1-5, as it resolved a known problem with the Gnu
linker described here that caused the same problem under Solaris 10.

http://sourceware.org/ml/binutils-cvs/2005-07/msg00121.html
http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html

- I have add followed various suggestions to work around the problem including
adding -dl to my CFLAGS, and other suggestions including removing -lc (wasn't
inserted by configure in my case anyway) and -dl from the linker parameters.

- As suggested in another place, inserted -shared in my link command for
svnadmin and surprisingly the link is successful in generating the binary. The
problem is that even for a simple invoke such as svnadmin --help, a segmentation
fault is produced.

My LD_LIBRARY_PATH is deliberately unset as I am using the -R option to link in
the pathing so that LD_LIBRARY_PATH is not relied on. This is necessary
particulary for the Solaris environment (which works with 1.2.3) as a long
LD_LIBRARY_PATH is IMHO not desirable.

Slowly going nuts about this, I hope someone out there could provide me with
some insight as I have never had any problems with building subversion in the
past. Is Core 4 suffering issues?

One question, should I need to blow away any binary that is installed (namely
subversion 1.2.0) that ships with Core 4. I don't think so but I welcome other
opinions.

Help appreciated and thanks,

Anthony

--
FOLLOWING IS INFORMATION ABOUT THE ENVIRONMENT:
My other build environment variables:
LDFLAGS=-R/usr/local/lib -R/usr/lib
CPPFLAGS=-I/usr/local/python2.3 -I/usr/local/include -I/usr/include
-L/usr/local/lib -L/usr/lib
CFLAGS=-fPIC -I/usr/local/python2.3 -I/usr/local/include -L/usr/local/lib -L/usr/lib
/configure --enable-shared --enable-dso=dlfcn --with-ssl --with-swig=/usr/local
--with-libs=/usr/local --with-libs= --with-apr=/usr/local/apr
--with-apr-util=/usr/local/apr --with-neon=/usr/local
PYTHON=/usr/local/bin/python2.3
NOTE: I've tried using -dl in my CFLAGS and CPPFLAGS. Also, I have tried both
current RPM's of libapr and building the source myself, the same result occurs.
Used both Subversion to build these libraries and as shown above had subversion
just use the libraries installed onto the system (by RPM or source).
Some diagnostics:
How I am attempting to link the binary for svnadmin.
[root@SMP-Fedora3 subversion-1.2.3]# cd subversion/svnadmin
[root@SMP-Fedora3 svnadmin]# /bin/sh /var/tmp/subversion-1.2.3/libtool --tag=CC
--silent --mode=link gcc  -fPIC -I/usr/local/python2.3 -I/usr/local/include
-L/usr/local/lib -L/usr/lib -pthread  -DNEON_ZLIB -DNEON_SSL  -R/usr/local/lib
-R/usr/lib -rpath /usr/local/lib -o svnadmin  main.o
../../subversion/libsvn_repos/libsvn_repos-1.la
../../subversion/libsvn_fs/libsvn_fs-1.la
../../subversion/libsvn_delta/libsvn_delta-1.la
../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/apr/lib/libaprutil-0.la
-lgdbm -ldb-4.3 -lexpat /usr/local/apr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl 
-lpthread
/usr/local/apr/lib/libapr-0.so: undefined reference to `dlerror'
/usr/local/apr/lib/libapr-0.so: undefined reference to `dlclose'
/usr/local/apr/lib/libapr-0.so: undefined reference to `dlopen'
/usr/local/apr/lib/libapr-0.so: undefined reference to `dlsym'
collect2: ld returned 1 exit status
[root@SMP-Fedora3 svnadmin]#
FROM config.log::
configure:4617: checking dlfcn.h usability
configure:4629: gcc -c -fPIC -I/usr/local/python2.3 -I/usr/local/include
-L/usr/local/lib -L/usr/lib   -pthread -I/usr/local/python2.3
-I/usr/local/include -I/usr/include -L/usr/local/lib -L/usr/lib   -DLINUX=2
-D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
conftest.c >&5
configure:4733: checking for dlfcn.h
configure:4740: result: yes
NOTE: The U below for dl variants below appears to match those for my successful
 Solaris 9 installation. So this doesn't appear to be the problem.
[root@SMP-Fedora3 subversion-1.2.3]# nm /usr/local/apr/lib/libapr-0.so |grep dl
00020740 T apr_os_dso_handle_get
000206e8 T apr_os_dso_handle_put
0001bdc9 T apr_thread_rwlock_rdlock
0001bdf9 T apr_thread_rwlock_tryrdlock
         U dlclose
         U dlerror
         U dlopen
         U dlsym
00022730 d __dso_handle
         U pthread_rwlock_rdlock@@GLIBC_2.1
         U pthread_rwlock_tryrdlock@@GLIBC_2.1
[root@SMP-Fedora3 subversion-1.2.3]# ldd /usr/local/apr/lib/libapr-0.so
        linux-gate.so.1 =>  (0x00f66000)
        librt.so.1 => /lib/librt.so.1 (0x007d9000)
        libm.so.6 => /lib/libm.so.6 (0x00b0a000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0070b000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00f42000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0042b000)
        libc.so.6 => /lib/libc.so.6 (0x00111000)
        /lib/ld-linux.so.2 (0x007a4000)
[root@SMP-Fedora3 subversion-1.2.3]#
[root@SMP-Fedora3 lib]# ls -la|grep libdl
-rwxr-xr-x   1 root root   14424 Aug 15 10:16 libdl-2.3.5.so
lrwxrwxrwx   1 root root      10 Sep  2 23:40 libdl.so -> libdl.so.2
lrwxrwxrwx   1 root root      14 Sep  3 10:13 libdl.so.2 -> libdl-2.3.5.so
[root@SMP-Fedora3 lib]# cd /usr/local/apr/lib
[root@SMP-Fedora3 lib]# ls -la|grep lib
-rw-r--r--  1 root root 213592 Sep  3 10:39 libapr-0.a
-rw-r--r--  1 root root    892 Sep  3 10:39 libapr-0.la
lrwxrwxrwx  1 root root     17 Sep  3 10:39 libapr-0.so -> libapr-0.so.0.9.6
lrwxrwxrwx  1 root root     17 Sep  3 10:39 libapr-0.so.0 -> libapr-0.so.0.9.6
-rwxr-xr-x  1 root root 174301 Sep  3 10:39 libapr-0.so.0.9.6
-rw-r--r--  1 root root 149008 Sep  3 10:44 libaprutil-0.a
-rw-r--r--  1 root root    887 Sep  3 10:44 libaprutil-0.la
lrwxrwxrwx  1 root root     21 Sep  3 10:44 libaprutil-0.so -> libaprutil-0.so.0.9.6
lrwxrwxrwx  1 root root     21 Sep  3 10:44 libaprutil-0.so.0 ->
libaprutil-0.so.0.9.6
-rwxr-xr-x  1 root root 120668 Sep  3 10:44 libaprutil-0.so.0.9.6
[root@SMP-Fedora3 lib]#
/usr/local/lib
[root@SMP-Fedora3 lib]# ls -la|grep libneon
-rw-r--r--   1 root root  162152 Sep  3 10:48 libneon.a
-rwxr-xr-x   1 root root     952 Sep  3 10:48 libneon.la
lrwxrwxrwx   1 root root      17 Sep  3 10:48 libneon.so -> libneon.so.24.0.7
lrwxrwxrwx   1 root root      17 Sep  3 10:48 libneon.so.24 ->
libneon.so.24.0.7-rwxr-xr-x   1 root root  139450 Sep  3 10:48 libneon.so.24.0.7
[root@SMP-Fedora3 lib]#
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org