On 6/1/06, Philip Martin <philip@codematters.co.uk> wrote:
> dionisos@tigris.org writes:
>
> > Author: dionisos
> > Date: Thu Jun 1 12:12:30 2006
> > New Revision: 19901
> >
> > Modified:
> > trunk/build.conf
> >
> > Log:
> > Workaround for build problems on OS X and (my) Debian with libtool 1.5.x
> >
> > Reorder dependencies, so that uninstalled libs are correctly found
> > when running the test framework.
> >
> > Found by: breser
> > dionisos
> >
> > Patch by: breser
>
> The log message should be include something like:
>
> * build.conf (svnsync, libsvn_ra_local): Adjust library order.
Propedited.
> > Modified: trunk/build.conf
> > URL: http://svn.collab.net/viewvc/svn/trunk/build.conf?pathrev=19901&r1=19900&r2=19901
> > ==============================================================================
> > --- trunk/build.conf (original)
> > +++ trunk/build.conf Thu Jun 1 12:12:30 2006
> > @@ -308,7 +308,7 @@
> > description = Subversion repository replicator
> > type = exe
> > path = subversion/svnsync
> > -libs = libsvn_ra libsvn_delta libsvn_subr apr
> > +libs = libsvn_subr libsvn_delta libsvn_ra apr
>
> There should be a comment in the "code", not the log message, to
> explain why this strange library order is needed.
Pending the outcome here, I'll add the comment you mean.
> > install = bin
> >
> >
> > @@ -697,9 +697,8 @@
> > path = subversion/tests/libsvn_ra_local
> > sources = ra-local-test.c
> > install = test
> > -libs = libsvn_test libsvn_ra_local libsvn_ra
> > - libsvn_fs libsvn_delta libsvn_subr
> > - aprutil apriconv apr
> > +libs = libsvn_subr libsvn_delta libsvn_fs libsvn_test
> > + libsvn_ra_local libsvn_ra aprutil apriconv apr
>
> ditto
> Is this change portable?
*No* idea. I posted about it before and got no reactions, so I decided
that it was either fine, or would trigger reactions upon commit... In
the post I also mentioned I'm not particularly familiar with linkage
problems (which is why I posted in the first place).
> Libraries are now being linked in the
> "wrong" order, libsvn_subr provides symbols that are used by libraries
> that are later in the link line.
Yes, I read the -l option description for GNU ld, but for ld (through
libtool) it seems to work...
> Has this been tested on any of the
> less common platforms like AIX, Solaris, HPUX, etc?
Nope.
> Does it work when the subversion libraries are static? Usually static
> libraries have to
> be specified in the correct order, are you just lucky that there are
> enough unresolved symbols when libsvn_subr is first encountered to
> pull all the objects from the library?
>
> I'd really like to know *why* this change is necessary. What changes
> in the svnsync executable? Is the problem with the link commands that
> run during the build, or is it the relink when the svnsync script is
> run?
I have no idea; I had not built svn on that box before, so, I've got
no idea if the executable was failing from the start or not...
> I realise it's frustrating when your build doesn't work, but until you
> can explain how this "magic" solves the problem I think it is
> premature to commit it.
But you're asking me to reverse engineer Darwin's dynamic linker?
> The discussion on the dev list just stopped
> without reaching a conclusion :( If you have "before" and "after"
> versions of the executable it must be possible to determine what
> changes -- on Linux at least, I can't speak for Darwin.
Before and after what? Ah! Failing! Ok. Backsearching first failure now.
The above sounds a bit frustrated, and frankly, it is: I want to do
the homework, I just don't know where it is, what it is or how to find
it... :-(
Thanks for the help. I'll followup when I find the first non-failing rev.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 2 21:34:24 2006