RE: Library load problem with Subversion upgrade [resend]

> -----Original Message-----
> From: David Tyler [mailto:dtyler_at_justicesystems.com]
> Sent: Wednesday, July 16, 2008 6:18 PM
> To: Thompson Nick (IFGB COM PS CE PLSA CA)
> Cc: users_at_subversion.tigris.org
> Subject: RE: Library load problem with Subversion upgrade [resend]
>
> > -----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
>
>
>

David,

I don't think that is the correct way to fix it. It was just a way to debug it. What you probably should do is make sure /usr/local/lib is in your /etc/ld.so.conf file (my guess is it is already there, since the other libraries are cached correctly) and run "ldconfig -v" to add this library to the cache as well. Then you will not need the LD_LIBRARY_PATH variable set.

My assumption is that before you upgraded, this missing library was not present, but the others in /usr/local/lib where. Ldconfig was run so that these old libs where cached. After the upgrade you had changed the other libs, but their paths where still correctly cached, and this new library appeared was added. It was not cached by ldconfig and since you had no LD_LIBRARY_PATH set, there was no way for ld to find it. Running ldconfig again should add this new library to the cache as well and so no LD_LIBRARY_PATH setting will be required.

I hope that makes sense :-)

Nick.

---------------------------------------------------------------------
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-17 10:56:47 CEST