#49: Subversion 1.6.2 explodes on first network access

Solved!
After compiling Subversion 1.6.2 from source on OS X 10.5 Leopard, the compilation is apparently successful, but svn dies when it tries to connect to the network for the first time. Crash log reports that symbols are missing from libneon.dylib.

Crash report from shell:
dyld: lazy symbol binding failed: Symbol not found: _ne_set_connect_timeout Referenced from: /usr/local/lib/libsvn_ra_neon-1.0.dylib Expected in: dynamic lookup dyld: Symbol not found: _ne_set_connect_timeout Referenced from: /usr/local/lib/libsvn_ra_neon-1.0.dylib Expected in: dynamic lookup

The SVN 1.6.2 makefile is mildly broken under certain conditions

3
The aforementioned problem happens if you have two copies of libneon -- one in /usr/lib, and the other in /usr/local/lib. This is because SVN's new Makefile in 1.6.2 is written such that GCC will blithely ignore your specified library path and link against whatever is in /usr/lib.

If you run
otool -L /usr/local/lib/libsvn_ra_neon-1.0.dylib, you'll find that the library was linked against /usr/lib/libneon.26.dylib . This is odd, because I'm sure you'd remember that you'd specified:
--with-neon=/usr/local when you ran configure. Unfortunately, if you look in the Makefile:

LDFLAGS = ... -L/usr/lib -L/usr/lib $(EXTRA_LDFLAGS)
... and a bunch of other places where the -L/usr/lib is explicitly specified in front of everything else.

When specifying load order using -L, GCC searches for libraries to link against in the order that they were given. It just so happens that Apple ships an older libneon in /usr/lib. Since /usr/lib is up first, its dynamic library will always win, no matter what you put in --with-neon=. So GCC links against old libneon and goes merrily on its way. Since Apple ships a dynamic library, this particular code path won't run until you access the features of libneon -- that is, network access. And so all is fine until the first time you run svn update.

If you change the leading -L to -L/usr/local/lib (or wherever your newer libneon is), it'll link correctly, and you'll have SVN back without the explosions.

MacPorts actually tries to fix this by disabling the neon version check for some reason. I'm concerned that all that really means is that you get to link against the Apple neon instead, and some features end up being missing, but I can't be sure about that.

Think you've got a better solution? Help 92049143cabb7ba896d7c06e19906303_small yliu out by posting your solution

Fixing undefined library symbols for compiling PHP 5.2.8 | The Sarth Repository

http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-compiling-php-528/ - found by 92049143cabb7ba896d7c06e19906303_small yliu on May 28, 2009, 06:12 AM UTC

It's the exact same issue as PHP, where the writers of the Makefile completely ignored the order of library linking.

Tags: library symbols load order

Nabble - Subversion Users - Subversion tries to link to wrong neon lib.

http://www.nabble.com/Subversion-tries-to-link-to-wrong-neon-lib.-td22724366.html - found by 92049143cabb7ba896d7c06e19906303_small yliu on May 28, 2009, 06:11 AM UTC

aha! the last message is instructive. It's linking against /usr/liblibneon.dylib. Fuckers.

Tags: mailing list libneon Subversion

Subversion Users: Re: Subversion tries to link to wrong neon lib.

http://svn.haxx.se/users/archive-2009-03/0738.shtml - found by 92049143cabb7ba896d7c06e19906303_small yliu on May 28, 2009, 06:13 AM UTC

doesn't seem right to me. Load paths on OS X are hard-coded to the library.

Tags: mailing list

/trunk/dports/devel/subversion/Portfile – MacPorts

http://trac.macports.org/browser/trunk/dports/devel/subversion/Portfile - found by 92049143cabb7ba896d7c06e19906303_small yliu on May 28, 2009, 06:08 AM UTC

The MacPorts port file. They disable neon-check for some reason.

Tags: Neon SVN compilation macports portfile