Actually the fix for darwin isn't that hard. You just need to make
sure than each shared library directly links against every other
shared library that it directly uses symbols from. (This allows you
to keep two level namespaces enabled). And this shouldn't negatively
affect any other platforms.
Then if you set DYLD_LIBRARY_PATH at runtime of the tests, the tests
can be installed anywhere you like.
In particular I recall that some of the swig bindings needed access
to the apr libraries. However the apr libs themselves didn't get
built to the location than the makefiles ended up searching on OS X.
If I recall correctly it was libs v/s .libs on the apr dir. I tried
submitting a patch for this about a year ago but was told to just
make install apr before building the bindings. If I can find some
time I can try looking into why things don't currently work for
trunk, but that might not be for another few weeks ;-(
Michael
On Aug 23, 2005, at 2:12 PM, Justin Erenkrantz wrote:
> --On August 21, 2005 5:27:37 PM +0100 Malcolm Rowe <malcolm-svn-
> dev@farside.org.uk> wrote:
>
>
>> Everything seemed to work fine, including the tests, and there
>> wasn't any
>> previous Subversion installation lying around, so it must have
>> picked up
>> the just-built libraries. (The ~/usr directory didn't even exist
>> until the
>> make install step ran).
>>
>
> So, if you use particular versions of GNU libtool, it'll cheat and
> build two sets of libraries and executables on Darwin: one that is
> built at 'make' that refers internally to the build directory time
> and one that is built at 'install' time that refers to the
> installed location.
>
> The cost of this means that the build is twice as slow on Darwin as
> everything must be compiled twice. I find that unacceptable; but I
> have also lots of other reasons why I think libtool is the
> scourge. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 24 17:13:30 2005