[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Library load problem with Subversion upgrade [resend]

From: David Tyler <dtyler_at_justicesystems.com>
Date: Wed, 16 Jul 2008 11:18:28 -0600

> -----Original Message-----
> From: David Tyler [mailto:dtyler_at_justicesystems.com]
> Sent: Wednesday, July 16, 2008 4:50 PM
> To: Marc Haisenko; users_at_subversion.tigris.org
> Subject: Re: Library load problem with Subversion upgrade [resend]
>
>
>
> >>> Marc Haisenko <haisenko_at_comdasys.com> 7/16/2008 09:32 AM >>>
> On Wednesday 16 July 2008, David Tyler wrote:
> > httpd: Syntax error on line 64 of
> /usr/local/apache2/conf/httpd.conf:
> > Cannot load /usr/local/apache2/modules/mod_dav_svn.so into server:
> > libsvn_fs_util-1.so.0: cannot open shared object file: No such
file
> or
> > directory
> >
> > [...]
> >
> > Output from ldd mod_dav_svn.so:
> > libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0
> > (0xb75ae000) libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0
> > (0xb75a9000) libsvn_delta-1.so.0 =>
> /usr/local/lib/libsvn_delta-1.so.0
> > (0xb75a0000) libsvn_subr-1.so.0 =>
/usr/local/lib/libsvn_subr-1.so.0
> > (0xb756f000) libpthread.so.0 => /lib/tls/libpthread.so.0
> (0xb755f000)
> > libc.so.6 => /lib/tls/libc.so.6 (0xb7428000)
> > libaprutil-1.so.0 =>
> /usr/local/apache2/lib/libaprutil-1.so.0
> > (0xb740d000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb73ed000)
> > libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0
> (0xb73cc000)
> > libuuid.so.1 => /lib/libuuid.so.1 (0xb73c9000)
> > librt.so.1 => /lib/tls/librt.so.1 (0xb73b5000)
> > libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7388000)
> > libdl.so.2 => /lib/libdl.so.2 (0xb7384000)
> > libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0
> > (0xb7368000) libsvn_fs_util-1.so.0 => not found
> > libz.so.1 => /usr/lib/libz.so.1 (0xb735a000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> > libsvn_fs_util-1.so.0 => not found
> >
> >
> > ls of "missing" library in /usr/local/lib:
> >
> > # ls -l libsvn_fs_util-1.so*
> > lrwxrwxrwx 1 root root 25 Jul 7 15:52
> libsvn_fs_util-1.so
> > -> libsvn_fs_util-1.so.0.0.0
> > lrwxrwxrwx 1 root root 25 Jul 7 15:52
> libsvn_fs_util-1.so.0 -> libsvn_fs_util-1.so.0.0.0
> > -rwxr-xr-x 1 root root 16671 Jul 7 15:52
> libsvn_fs_util-1.so.0.0.0
>
> Well, the data presented suggests that the library is there, at the
> expected
> place/name but maybe it can't be loaded. So maybe it's corrupted ?
Try
>
> running:
>
> file /usr/local/lib/libsvn_fs_util-1.so.0.0.0
>
> and
>
> objdump -T /usr/local/lib/libsvn_fs_util-1.so.0.0.0
>
> What do they return ?
> Marc
>
> --
> Marc Haisenko
>
> Comdasys AG
> Rüdesheimer Str. 7
> 80686 München
> Germany
>
> Tel.: +49 (0)89 548 433 321
>
> --
>
> The output from the file command is:
>
> $ file /usr/local/lib/libsvn_fs_util-1.so.0.0.0
> /usr/local/lib/libsvn_fs_util-1.so.0.0.0: ELF 32-bit LSB shared
object,
> Intel 80386, version 1 (SYSV), not stripped
>
>
>
> The output from the objdump command is:
>
> [svn_at_abqlx1 svn]$ objdump -T
/usr/local/lib/libsvn_fs_util-1.so.0.0.0
>
> /usr/local/lib/libsvn_fs_util-1.so.0.0.0: file format elf32-i386
>
> DYNAMIC SYMBOL TABLE:
> 000000b4 l d .hash 00000000
> 0000021c l d .dynsym 00000000
> 0000054c l d .dynstr 00000000
> 00000736 l d .gnu.version 00000000
> 0000079c l d .gnu.version_r 00000000
> 000007cc l d .rel.dyn 00000000
> 000007f4 l d .rel.plt 00000000
> 00000844 l d .init 00000000
> 0000085c l d .plt 00000000
> 0000090c l d .text 00000000
> 00000c10 l d .fini 00000000
> 00000c40 l d .rodata 00000000
> 00000d00 l d .eh_frame 00000000
> 00001d04 l d .data 00000000
> 00001d0c l d .dynamic 00000000
> 00001e24 l d .ctors 00000000
> 00001e2c l d .dtors 00000000
> 00001e34 l d .jcr 00000000
> 00001e38 l d .got 00000000
> 00001e78 l d .bss 00000000
> 00000000 l d .comment 00000000
> 00000000 l d .debug_aranges 00000000
> 00000000 l d .debug_pubnames 00000000
> 00000000 l d .debug_info 00000000
> 00000000 l d .debug_abbrev 00000000
> 00000000 l d .debug_line 00000000
> 00000000 l d .debug_frame 00000000
> 00000000 l d .debug_str 00000000
> 00000000 l d .debug_ranges 00000000
> 00000b78 g DF .text 00000064 Base
svn_fs__next_entry_name
> 00000000 DF *UND* 00000167 GLIBC_2.0 strchr
> 00001d0c g DO *ABS* 00000000 Base _DYNAMIC
> 000009d8 g DF .text 000000f8 Base
> svn_fs__canonicalize_abspath
> 00000000 DF *UND* 00000048 svn_error_create
> 00000000 DF *UND* 0000004c GLIBC_2.0 dcgettext
> 00000000 DF *UND* 00000027 svn_error__locate
> 00000844 g DF .init 00000000 Base _init
> 00000000 DF *UND* 00000054 apr_pstrdup
> 00000ad0 g DF .text 000000a5 Base svn_fs__check_fs
> 00000000 DF *UND* 0000010c apr_palloc
> 00001e78 g D *ABS* 00000000 Base __bss_start
> 00000000 DF *UND* 00000065 apr_pstrndup
> 00000c10 g DF .fini 00000000 Base _fini
> 00000000 w DF *UND* 0000009a GLIBC_2.1.3 __cxa_finalize
> 00001e78 g D *ABS* 00000000 Base _edata
> 00001e38 g DO *ABS* 00000000 Base _GLOBAL_OFFSET_TABLE_
> 00001e7c g D *ABS* 00000000 Base _end
> 00000000 DF *UND* 00000043 GLIBC_2.0 memset
> 00000000 w D *UND* 00000000 _Jv_RegisterClasses
> 00000000 w D *UND* 00000000 __gmon_start__
>
>
>
>

>>> <Nick.Thompson_at_infineon.com> 7/16/2008 10:43 AM >>>
Is /usr/local/lib in your LD_LIBRARY_PATH or is the linker picking up
the other /usr/local/lib stuff because ldconfig was run when they where
present, but before the "missig" lib was present?

What is in your LD_LIBRARY_PATH?

If it doesn't have /usr/local/lib, can you add it and try your ldd
command again?

Try running "ldconfig -p" to see what is in its cache.

Nick.

There was no LD_LIBRARY_PATH environment variable set. I ran "export
LD_LIBRARY_PATH=/usr/local/lib" followed by "ldd mod_dav_svn.so" and
recieved the following output:

        libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0
(0xb75be000)
        libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0
(0xb75b9000)
        libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
(0xb75b0000)
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
(0xb757f000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb755f000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7428000)
        libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0
(0xb740d00
0)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb73ed000)
        libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0
(0xb73cc000)
        libuuid.so.1 => /lib/libuuid.so.1 (0xb73c9000)
        librt.so.1 => /lib/tls/librt.so.1 (0xb73b5000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7388000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7384000)
        libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0
(0xb7368000)
        libsvn_fs_util-1.so.0 => /usr/local/lib/libsvn_fs_util-1.so.0
(0xb736600
0)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7358000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

This does appear to have solved the problem. Apache starts normally
now and I am able to access the repository through my web browser. I am
curious as to how the other libraries located in /usr/local/lib were
found, but not this one. Well the important thing is that it is working
now.

I have added this variable setting ("LD_LIBRARY_PATH=/usr/local/lib")
to /etc/init.d/httpd script so that apachectl should run correctly when
the system reboots. I have also added the line "export
LD_LIBRARY_PATH=/usr/local/lib" to the end of the /etc/profile for
regular login use.

Thank you very much Marc and Nick for your time in helping me solve
this problem. I have reformatted the reply to be top down and I am
carbon copying the mailing list in this reply so that the solution may
be archived for future users.

Thanks again,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-16 19:19:15 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.