Subversion and undefined symbols

Posted on by yiming

This is fast turning out to be a blog about compiling open source software. Maybe I should change the title.

You may get this error while trying to compile Subversion 1.5.2:
ld: Undefined symbols:
_svn_fs_txn_root_base_revision referenced from libsvn expected to be defined in libsvn
_svn_fs_change_txn_props referenced from libsvn expected to be defined in libsvn
_svn_fs_get_mergeinfo referenced from libsvn expected to be defined in libsvn
_svn_fs_recover referenced from libsvn expected to be defined in libsvn
_svn_fs_upgrade referenced from libsvn expected to be defined in libsvn
_svn_fs_node_origin_rev referenced from libsvn expected to be defined in libsvn
/usr/bin/libtool: internal link edit command failed
make: *** [subversion/libsvn_ra_local/libsvn_ra_local-1.la] Error 1

Turns out there may be a bug in the libtool script shipped with the source tarball, under certain circumstances with OS X 10.4, that causes it to fail to link. Ah, libtool, you make my life so much harder sometimes.

If you copy /usr/bin/glibtool over $SRCDIR/libtool (that is, into the directory for the subversion source code, replacing the one that is placed there by the package itself), the package should compile with no further complaints. make test also shows success on all tests, so this seems a satisfactory solution.

UPDATE 1/31/2009
I’ve been informed in the comments that MacPorts may rely on source compilation from tarball, and thus have this issue. If you’re having this issue with the MacPorts SVN package, please check out the advice in the comment section from farkinga, who has additional notes.

O(n) person in an O(log n) world

4 Replies to “Subversion and undefined symbols”

  2. Thanks for submitting this. It’s a fairly obscure edge case, so I figure no one will care but the few people who run into it, and so I didn’t bother doing any further debugging. I’d guess very few people even try to compile SVN on OS X from raw tarball these days. But if it does turn out to be something worth investigating, then it’s definitely good for it be out there beyond my compilation notes.

  3. Great! This is exactly what I was looking for. I am using Intel OS X 10.4

    Macports indirectly relies on the raw tarball (I believe) so this might not be such a rare case, after all… I tried filing a bug about this with macports, but alas their copy of trac doesn’t appear to be functioning at the moment. There’s a related post at http://www.nabble.com/libtool-shipped-with-subversion-1.5.5-is-b0rk3d-on-Macports.-td21443432.html

    I install macports stuff into /opt/local, so I copied /opt/local/bin/glibtool instead of /usr/bin/glibtool, but with that minor change, everything worked for me.

    Thanks!

Comments are closed.