You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2002/06/11 15:05:55 UTC
broken libtool on freebsd
Hey Garrett, as fellow FreeBSD user, I thought you could shed some
light on this question. Maybe others can comment as well.
I have this awful resistance to building svn shared and installing it;
I usually just build statically and make /usr/local/bin/svn a symlink
to the static binary in my source tree.
The reason for this is that libtool 1.4 seems to have a wonky behavior
on FreeBSD: whenever something is linked during a compile, libtool
will use whatever libsvn_* libraries are installed in /usr/local/lib/,
no matter what. On other platforms, apparently this isn't true. Greg
Stein builds shared all the time, and never runs into this problem.
Just to verify this, I'll build a shared binary, and then run 'ldd' on
.libs/lt-svn. Sure enough, all of the libraries resolve to ones in
/usr/local/lib, instead of the freshly-built ones in my source tree.
This is *not* how libtool is supposed to work.
Maybe libtool is somehow invoking the linker incorrectly, or some kind
of -rpath switch isn't working? Maybe my system is horked? Does
anyone else ever see this problem?
(I'm using FreeBSD 4.5-STABLE.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Just to verify this, I'll build a shared binary, and then run 'ldd' on
> .libs/lt-svn. Sure enough, all of the libraries resolve to ones in
> /usr/local/lib, instead of the freshly-built ones in my source tree.
> This is *not* how libtool is supposed to work.
>
> Maybe libtool is somehow invoking the linker incorrectly, or some kind
> of -rpath switch isn't working? Maybe my system is horked? Does
> anyone else ever see this problem?
It works for me on my Linux box. I build shared most of the time.
The lt-svn executable is created when you run the clients/cmdline/svn
script. If you delete lt-svn and run the svn script, lt-svn should be
recreated. The script contains a 'relink_command' that specifies the
necessary libraries and rpath options. Looking at that command I see
relative path libraries such as
../../../subversion/libsvn_ra/.libs/libsvn_ra.so
absolute path libraries such as
/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs/libsvn_wc.so
and --rpath options such as
-Wl,--rpath -Wl,/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs
As far as I can see the relative path libraries are the explicit
dependencies, and the absolute path libraries arise when one
Subversion library depends on another. Within my build tree, any
Subversion libraries that are linked to other Subversion libraries
resolve those links within the tree.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Wed, Jun 12, 2002 at 09:53:41AM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
> > Hmmm, you don't have $LD_LIBRARY_PATH set to /usr/local/lib do you? If
> > not I'm out of guesses...
>
> Hm, yeah, I *do* have LD_LIBRARY_PATH set to .:/usr/local/lib. I
> think it gets set in my .bash_profile.
>
> Is that environment variable really so strong?
>
> Holy cow. I guess so! I just unset the variable, and now 'ldd
> lt-svn' resolves all libraries to ones within my build tree, just as
> it should be.
>
> Wow, I just don't get it... I thought the runtime loader always looked
> at compile-time 'rpaths' first, before anything else...
Looks like it used to in FreeBSD, but that behaviour switched:
http://www.freebsd.org/cgi/query-pr.cgi?pr=28191
(According to the man page, Linux ld.so does search RPATHs before
LD_LIBRARY_PATH)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> On Tue, Jun 11, 2002 at 04:46:03PM -0500, Ben Collins-Sussman wrote:
> > Joe Orton <jo...@manyfish.co.uk> writes:
> >
> > > If you truss lt-svn, is it opening the libs directly out of
> > > /usr/local/lib first (and not trying anywhere else beforehand)?
> >
> > Nope, according to truss, lt-svn attempts to open each libsvn library
> > in "." first, (i.e. "./libsvn_client.so"). That fails, and then it
> > immediately succeeds in opening the library out of /usr/local/lib/.
>
> Hmmm, you don't have $LD_LIBRARY_PATH set to /usr/local/lib do you? If
> not I'm out of guesses...
Hm, yeah, I *do* have LD_LIBRARY_PATH set to .:/usr/local/lib. I
think it gets set in my .bash_profile.
Is that environment variable really so strong?
Holy cow. I guess so! I just unset the variable, and now 'ldd
lt-svn' resolves all libraries to ones within my build tree, just as
it should be.
Wow, I just don't get it... I thought the runtime loader always looked
at compile-time 'rpaths' first, before anything else...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Jun 11, 2002 at 04:46:03PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > If you truss lt-svn, is it opening the libs directly out of
> > /usr/local/lib first (and not trying anywhere else beforehand)?
>
> Nope, according to truss, lt-svn attempts to open each libsvn library
> in "." first, (i.e. "./libsvn_client.so"). That fails, and then it
> immediately succeeds in opening the library out of /usr/local/lib/.
Hmmm, you don't have $LD_LIBRARY_PATH set to /usr/local/lib do you? If
not I'm out of guesses...
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Joe Orton <jo...@manyfish.co.uk> writes:
> >
> > > If you truss lt-svn, is it opening the libs directly out of
> > > /usr/local/lib first (and not trying anywhere else beforehand)?
> >
> > Nope, according to truss, lt-svn attempts to open each libsvn library
> > in "." first, (i.e. "./libsvn_client.so"). That fails, and then it
> > immediately succeeds in opening the library out of /usr/local/lib/.
>
> Does freebsd support LD_DEBUG? On Linux I can do
>
> % LD_DEBUG=libs lt-svn
Nope. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > If you truss lt-svn, is it opening the libs directly out of
> > /usr/local/lib first (and not trying anywhere else beforehand)?
>
> Nope, according to truss, lt-svn attempts to open each libsvn library
> in "." first, (i.e. "./libsvn_client.so"). That fails, and then it
> immediately succeeds in opening the library out of /usr/local/lib/.
Does freebsd support LD_DEBUG? On Linux I can do
% LD_DEBUG=libs lt-svn
...
13092: find library=libsvn_client.so.0; searching
13092: search path=/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/i
686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/i686:/home/pm/
sw/subversion/obj/subversion/libsvn_client/.libs/mmx:/home/pm/sw/subversion/obj/
subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_wc/.
libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_wc/.libs/i686:/home/p
m/sw/subversion/obj/subversion/libsvn_wc/.libs/mmx:/home/pm/sw/subversion/obj/su
bversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs/i
686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs/i686:/home/pm/sw/s
ubversion/obj/subversion/libsvn_ra/.libs/mmx:/home/pm/sw/subversion/obj/subversi
on/libsvn_ra/.libs:/home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs/i
686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs/i686:/home/p
m/sw/subversion/obj/subversion/libsvn_ra_local/.libs/mmx:/home/pm/sw/subversion/
obj/subversion/libsvn_ra_local/.libs:/home/pm/sw/subversion/obj/subversion/libsv
n_repos/.libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs/
i686:/home/pm/sw/subversion/obj/subversion/libsvn_repos/.libs/mmx:/home/pm/sw/su
bversion/obj/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj/subversion
/libsvn_fs/.libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs/
i686:/home/pm/sw/subversion/obj/subversion/libsvn_fs/.libs/mmx:/home/pm/sw/subve
rsion/obj/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj/subversion/libsv
n_delta/.libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs/
i686:/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs/mmx:/home/pm/sw/su
bversion/obj/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj/subversion
/libsvn_ra_dav/.libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libsvn_ra_da
v/.libs/i686:/home/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs/mmx:/home
/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs:/home/pm/sw/subversion/obj/
subversion/libsvn_subr/.libs/i686/mmx:/home/pm/sw/subversion/obj/subversion/libs
vn_subr/.libs/i686:/home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs/mmx:/
home/pm/sw/subversion/obj/subversion/libsvn_subr/.libs:/usr/local/apache2/lib/i6
86/mmx:/usr/local/apache2/lib/i686:/usr/local/apache2/lib/mmx:/usr/local/apache2
/lib:/usr/local/neon-0.21.1/lib/i686/mmx:/usr/local/neon-0.21.1/lib/i686:/usr/lo
cal/neon-0.21.1/lib/mmx:/usr/local/neon-0.21.1/lib:/usr/local/subversion/lib/i68
6/mmx:/usr/local/subversion/lib/i686:/usr/local/subversion/lib/mmx:/usr/local/su
bversion/lib (RPATH from file lt-svn)
13092: trying file=/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/
i686/mmx/libsvn_client.so.0
13092: trying file=/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/
i686/libsvn_client.so.0
13092: trying file=/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/
mmx/libsvn_client.so.0
13092: trying file=/home/pm/sw/subversion/obj/subversion/libsvn_client/.libs/
libsvn_client.so.0
13092:
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> If you truss lt-svn, is it opening the libs directly out of
> /usr/local/lib first (and not trying anywhere else beforehand)?
Nope, according to truss, lt-svn attempts to open each libsvn library
in "." first, (i.e. "./libsvn_client.so"). That fails, and then it
immediately succeeds in opening the library out of /usr/local/lib/.
> Does "ldconfig -r" give any cached locations for the SVN libs?
$ ldconfig -r | grep libsvn
326:-lsvn_subr.0 => /usr/local/lib/libsvn_subr.so.0
327:-lsvn_delta.0 => /usr/local/lib/libsvn_delta.so.0
328:-lsvn_ra_dav.0 => /usr/local/lib/libsvn_ra_dav.so.0
329:-lsvn_fs.0 => /usr/local/lib/libsvn_fs.so.0
330:-lsvn_repos.0 => /usr/local/lib/libsvn_repos.so.0
331:-lsvn_ra_local.0 => /usr/local/lib/libsvn_ra_local.so.0
332:-lsvn_ra.0 => /usr/local/lib/libsvn_ra.so.0
333:-lsvn_wc.0 => /usr/local/lib/libsvn_wc.so.0
334:-lsvn_client.0 => /usr/local/lib/libsvn_client.so.0
335:-lsvn_swig_py.0 => /usr/local/lib/libsvn_swig_py.so.0
What's the diagnosis, doctor?
Is it serious?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Jun 11, 2002 at 04:02:05PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > > Just to verify this, I'll build a shared binary, and then run 'ldd' on
> > > .libs/lt-svn. Sure enough, all of the libraries resolve to ones in
> > > /usr/local/lib, instead of the freshly-built ones in my source tree.
> > > This is *not* how libtool is supposed to work.
> >
> > Does "objdump -p lt-svn | grep RPATH" give something appropriate? (i.e.
> > not listing /usr/local/lib before anything else).
>
> [sussman@kepler:~/projects/svn/subversion/clients/cmdline/.libs]$ objdump -p lt-svn | grep RPATH
> RPATH /usr/home/sussman/projects/svn/subversion/libsvn_client/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_wc/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra_local/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_repos/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_fs/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_delta/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra_dav/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_subr/.libs:/usr/home/sussman/projects/svn/apr-util/.libs:/usr/home/sussman/projects/svn/apr-util/xml/expat/lib/.libs:/usr/home/sussman/projects/svn/apr/.libs:/usr/home/sussman/projects/svn/neon/src/.libs:/usr/local/lib
If you truss lt-svn, is it opening the libs directly out of
/usr/local/lib first (and not trying anywhere else beforehand)?
Does "ldconfig -r" give any cached locations for the SVN libs?
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> > Just to verify this, I'll build a shared binary, and then run 'ldd' on
> > .libs/lt-svn. Sure enough, all of the libraries resolve to ones in
> > /usr/local/lib, instead of the freshly-built ones in my source tree.
> > This is *not* how libtool is supposed to work.
>
> Does "objdump -p lt-svn | grep RPATH" give something appropriate? (i.e.
> not listing /usr/local/lib before anything else).
[sussman@kepler:~/projects/svn/subversion/clients/cmdline/.libs]$ objdump -p lt-svn | grep RPATH
RPATH /usr/home/sussman/projects/svn/subversion/libsvn_client/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_wc/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra_local/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_repos/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_fs/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_delta/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_ra_dav/.libs:/usr/home/sussman/projects/svn/subversion/libsvn_subr/.libs:/usr/home/sussman/projects/svn/apr-util/.libs:/usr/home/sussman/projects/svn/apr-util/xml/expat/lib/.libs:/usr/home/sussman/projects/svn/apr/.libs:/usr/home/sussman/projects/svn/neon/src/.libs:/usr/local/lib
[sussman@kepler:~/projects/svn/subversion/clients/cmdline/.libs]$ ldd lt-svn
lt-svn:
libsvn_client.so.0 => /usr/local/lib/libsvn_client.so.0 (0x28074000)
libsvn_wc.so.0 => /usr/local/lib/libsvn_wc.so.0 (0x28088000)
libsvn_ra.so.0 => /usr/local/lib/libsvn_ra.so.0 (0x280a9000)
libsvn_ra_local.so.0 => /usr/local/lib/libsvn_ra_local.so.0 (0x280ac000) libsvn_repos.so.0 => /usr/local/lib/libsvn_repos.so.0 (0x280b2000)
libsvn_fs.so.0 => /usr/local/lib/libsvn_fs.so.0 (0x280c1000)
libsvn_delta.so.0 => /usr/local/lib/libsvn_delta.so.0 (0x280e0000)
libdb4.so.0 => /usr/local/lib/libdb4.so.0 (0x280ef000)
libsvn_ra_dav.so.0 => /usr/local/lib/libsvn_ra_dav.so.0 (0x28175000)
libsvn_subr.so.0 => /usr/local/lib/libsvn_subr.so.0 (0x28185000)
libaprutil.so.0 => /usr/local/lib/libaprutil.so.0 (0x2819d000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x281ad000)
libapr.so.0 => /usr/local/lib/libapr.so.0 (0x281c9000)
libneon.so.21 => /usr/local/lib/libneon.so.21 (0x281e2000)
libm.so.2 => /usr/lib/libm.so.2 (0x281f9000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28215000)
libc.so.4 => /usr/lib/libc.so.4 (0x2822e000)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Jun 11, 2002 at 10:05:55AM -0500, Ben Collins-Sussman wrote:
>
> Hey Garrett, as fellow FreeBSD user, I thought you could shed some
> light on this question. Maybe others can comment as well.
>
> I have this awful resistance to building svn shared and installing it;
> I usually just build statically and make /usr/local/bin/svn a symlink
> to the static binary in my source tree.
>
> The reason for this is that libtool 1.4 seems to have a wonky behavior
> on FreeBSD: whenever something is linked during a compile, libtool
> will use whatever libsvn_* libraries are installed in /usr/local/lib/,
> no matter what. On other platforms, apparently this isn't true. Greg
> Stein builds shared all the time, and never runs into this problem.
>
> Just to verify this, I'll build a shared binary, and then run 'ldd' on
> .libs/lt-svn. Sure enough, all of the libraries resolve to ones in
> /usr/local/lib, instead of the freshly-built ones in my source tree.
> This is *not* how libtool is supposed to work.
Does "objdump -p lt-svn | grep RPATH" give something appropriate? (i.e.
not listing /usr/local/lib before anything else).
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken libtool on freebsd
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Tue, Jun 11, 2002 at 10:05:55AM -0500, Ben Collins-Sussman wrote:
>
> Hey Garrett, as fellow FreeBSD user, I thought you could shed some
> light on this question. Maybe others can comment as well.
>
> I have this awful resistance to building svn shared and installing it;
> I usually just build statically and make /usr/local/bin/svn a symlink
> to the static binary in my source tree.
>
> The reason for this is that libtool 1.4 seems to have a wonky behavior
> on FreeBSD: whenever something is linked during a compile, libtool
> will use whatever libsvn_* libraries are installed in /usr/local/lib/,
> no matter what. On other platforms, apparently this isn't true. Greg
> Stein builds shared all the time, and never runs into this problem.
>
> Just to verify this, I'll build a shared binary, and then run 'ldd' on
> .libs/lt-svn. Sure enough, all of the libraries resolve to ones in
> /usr/local/lib, instead of the freshly-built ones in my source tree.
> This is *not* how libtool is supposed to work.
>
> Maybe libtool is somehow invoking the linker incorrectly, or some kind
> of -rpath switch isn't working? Maybe my system is horked? Does
> anyone else ever see this problem?
i have seen this problem in the past, and as a result i also tend to
build statically. i haven't tried doing it lately, but i would assume
the problem still exists.
unfortunately, i don't know enough about libtool to say what's going
on, and i'm not even in front of a FreeBSD machine at the moment (i'm
out as USENIX for the week) so i can't even verify that it is indeed
still happening to me.
i do recall this happening to me a long time ago (having it like
against libs in /usr/local when it should have been linking against
the ones i was compiling locally), and i just assumed it was an issue
with our build system, not libtool itself. isn't that why we have the
'how to clean out your tree before compiling' instructions?
wish i could be more help,
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org