On Sat, Oct 09, 2004 at 09:56:36PM +0100, Philip Martin wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
>
> > As I understand it, symbol versioning would allow people to successfully
> > link against consumers of two different major versions of our
> > libraries. (The OSX two-level namespace would allow the same, I
> > believe.)
>
> That's right. I think we could also use it to prevent the internal
> svn_xxx__yyy symbols leaking out, although that may well require
> changes to the way the test suite is linked.
I've tried writing patches for this a few times using libtool's
-export-symbols-regex as attached, it's a little tricky coming up with a
good regex which defines only the public symbol names but not the __,
maybe I overcomplicated; and it reveals quite a few cases which strictly
look like interface violations currently:
add-cmd.o(.text+0x69): In function `svn_cl__add':
subversion/clients/cmdline/add-cmd.c:60: undefined reference to `svn_error__locate'
... and quite a few more like that in various places
log-cmd.o(.text+0x2d8): In function `log_message_receiver':
subversion/clients/cmdline/log-cmd.c:258: undefined reference to `svn_sort__hash'
ls-cmd.o(.text+0x19): In function `print_dirents':
subversion/clients/cmdline/ls-cmd.c:45: undefined reference to `svn_sort__hash'
subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so: undefined reference to `svn_txdelta__apply_instructions'
subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so: undefined reference to `svn_txdelta__copy_window'
subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so: undefined reference to `svn_txdelta__compose_windows'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 10 02:36:43 2004