You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2007/12/05 00:02:01 UTC
libtool issue
Hi,
I spent a bit of time looking at what I'll call the "libtool issue".
Basically, anyone compiling subversion trunk on an ELF platform
should have seen this, given that they also have a subversion package
provided by the OS installed on their system. I know that it happens
on Debian (confirmed by Karl), FreeBSD (run ldd on the binary to see
crazy linkage), and OpenBSD (compile fails).
The symptom in general is that compiling current trunk ends with
unresolved symbol errors in various libsvn_* libraries.
I've talked to Karl about this at Subconf, and he told me about
his workaround: Move system subversion libraries out of /usr/lib
or /usr/local/lib or wherever you have them into /tmp, compile svn,
then move the libs back.
During my investigation I found a better workaround that fits my
cause, requires less work and makes it possible to run the system
svn while compiling (nice on slow laptops like mine):
./configure --disable-shared
:)
Anyway, from reading the libtool docs it seems the proper fix
would be to consistently use version numbers for subversion libraries.
This would mean passing a '-version-info' parameter to libtool
somewhere in the build scripts and carefully maintaining this
parameter for all eternity:
http://www.gnu.org/software/libtool/manual.html#Versioning
Having system svn libraries installed as libsvn_*-1.la and compiling
the trunk ones with the same version number seems to be why libtool
gets confused and picks up libraries in /usr/lib when it should use
the ones in the working copy (various .libs/ directories).
Also, I don't get why libs compiled inside the working copy
have version number zero, but that is probably a libtoolism
that just looks weird but works for some reason.
Has anyone looked more deeply into this than I have?
Is there a particular reason why library versioning isn't already
being done?
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: libtool issue
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Dec 05, 2007 at 10:57:44AM +0000, Joe Orton wrote:
> On Wed, Dec 05, 2007 at 01:02:01AM +0100, Stefan Sperling wrote:
> > Basically, anyone compiling subversion trunk on an ELF platform
> > should have seen this, given that they also have a subversion package
> > provided by the OS installed on their system. I know that it happens
> > on Debian (confirmed by Karl), FreeBSD (run ldd on the binary to see
> > crazy linkage), and OpenBSD (compile fails).
>
> Subversion (unnecessarily) links executables using "-rpath $(libdir)",
> so if you have old libraries in $(libdir) at build time it should be
> expected that odd things will happen.
Ah, nice hint. It does look like this is a problem.
Quoting the ld man page with emphasis added by me:
-rpath dir
Add a directory to the runtime library search path.
This is used when linking an ELF executable with
shared objects. All -rpath arguments are concatenated
and passed to the runtime linker, which uses them to
locate shared objects at runtime. The -rpath option
^^^^^^^^^^^^^^^^^^
is also used when locating shared objects which are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
needed by shared objects explicitly included in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
link; see the description of the -rpath-link option.
^^^^
> I have previously argued that this is incorrect, and we've been fixing
> it in the Fedora Subversion package for a long time, as below.
I've applied this patch to current svn trunk and tried to build
subversion from scratch after 'make distclean' on OpenBSD 4.2-current
-> no success :(
Just to show people what I am seeing, below you can see:
1. The standard link command and output it genenerates.
2. The link command and output it generates without -rpath.
Basically same as 1, this is what the -rpath patch produces for me.
3. The command and output of a manual link where I moved all
the -L flags to the end of the command line. Linking somehow
succeeds with warnings, but the program does not run from the working
copy even though it should run using the libtool wrapper script...
1:
cd subversion/svn && /bin/sh /home/stsp/elego/svn-tigris/libtool --tag=CC --silent --mode=link gcc -g -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -L/usr/local/lib/db4 -L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/lib -rpath /usr/local/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb -lexpat -liconv /usr/local/lib/libapr-1.la /usr/local/lib/libneon.la
/home/stsp/elego/svn-tigris/subversion/libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0.0: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libsasl2.so.2.22: warning: sprintf() is often misused, please use snprintf()
/usr/local/lib/libsasl2.so.2.22: warning: strcat() is almost always misused, please use strlcat()
/usr/bin/ld: warning: libsvn_subr-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_subr-1.so.0.0
/usr/bin/ld: warning: libsvn_delta-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_delta-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_fs-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_base-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs_base-1.so.0.0
/usr/bin/ld: warning: libsvn_fs-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_repos-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_repos-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_local-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra_local-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_svn-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra_svn-1.so.0.0
/usr/bin/ld: warning: libsvn_ra-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra-1.so.0.0
/usr/bin/ld: warning: libsvn_diff-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_diff-1.so.0.0
/usr/bin/ld: warning: libsvn_wc-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_wc-1.so.0.0
add-cmd.o(.text+0x167): In function `svn_cl__add':
subversion/svn/add-cmd.c:68: undefined reference to `svn_client_add4'
blame-cmd.o(.text+0x76c): In function `svn_cl__blame':
subversion/svn/blame-cmd.c:304: undefined reference to `svn_client_blame4'
changelist-cmd.o(.text+0x52): In function `svn_cl__changelist':
subversion/svn/changelist-cmd.c:55: undefined reference to `svn_client_get_changelist'
changelist-cmd.o(.text+0x26b):subversion/svn/changelist-cmd.c:106: undefined reference to `svn_client_add_to_changelist'
changelist-cmd.o(.text+0x2b3):subversion/svn/changelist-cmd.c:123: undefined reference to `svn_client_remove_from_changelist'
checkout-cmd.o(.text+0x34e): In function `svn_cl__checkout':
subversion/svn/checkout-cmd.c:159: undefined reference to `svn_client_checkout3'
commit-cmd.o(.text+0x1e4): In function `svn_cl__commit':
subversion/svn/commit-cmd.c:102: undefined reference to `svn_client_commit4'
copy-cmd.o(.text+0x2f1): In function `svn_cl__copy':
subversion/svn/copy-cmd.c:135: undefined reference to `svn_client_copy4'
delete-cmd.o(.text+0x181): In function `svn_cl__delete':
subversion/svn/delete-cmd.c:76: undefined reference to `svn_client_delete3'
diff-cmd.o(.text+0x4c3): In function `svn_cl(double, int, float, float)':
subversion/svn/diff-cmd.c:197: undefined reference to `svn_client_get_changelist'
diff-cmd.o(.text+0xb26):subversion/svn/diff-cmd.c:344: undefined reference to `svn_client_diff_summarize2'
diff-cmd.o(.text+0xbb2):subversion/svn/diff-cmd.c:356: undefined reference to `svn_client_diff4'
diff-cmd.o(.text+0xcaa):subversion/svn/diff-cmd.c:388: undefined reference to `svn_client_diff_summarize_peg2'
diff-cmd.o(.text+0xd3d):subversion/svn/diff-cmd.c:400: undefined reference to `svn_client_diff_peg4'
export-cmd.o(.text+0x19b): In function `svn_cl__export':
subversion/svn/export-cmd.c:79: undefined reference to `svn_client_export4'
import-cmd.o(.text+0x1e1): In function `svn_cl__import':
subversion/svn/import-cmd.c:115: undefined reference to `svn_client_import3'
info-cmd.o(.text+0xeae): In function `svn_cl__info':
subversion/svn/info-cmd.c:459: undefined reference to `svn_client_get_changelist'
info-cmd.o(.text+0x10fa):subversion/svn/info-cmd.c:523: undefined reference to `svn_client_info2'
list-cmd.o(.text+0x991): In function `svn_cl__list':
subversion/svn/list-cmd.c:284: undefined reference to `svn_client_list2'
lock-cmd.o(.text+0x141): In function `svn_cl__lock':
subversion/svn/lock-cmd.c:94: undefined reference to `svn_client_get_changelist'
log-cmd.o(.text+0x94b): In function `svn_cl__log':
subversion/svn/log-cmd.c:475: undefined reference to `svn_client_get_changelist'
log-cmd.o(.text+0xe18):subversion/svn/log-cmd.c:613: undefined reference to `svn_client_log4'
log-cmd.o(.text+0xf0e):subversion/svn/log-cmd.c:637: undefined reference to `svn_client_log4'
merge-cmd.o(.text+0x62e): In function `svn_cl__merge':
subversion/svn/merge-cmd.c:229: undefined reference to `svn_client_merge_peg3'
merge-cmd.o(.text+0x67f):subversion/svn/merge-cmd.c:244: undefined reference to `svn_client_merge3'
mergeinfo-cmd.o(.text+0x225): In function `svn_cl__mergeinfo':
subversion/svn/mergeinfo-cmd.c:109: undefined reference to `svn_client_mergeinfo_get_merged'
mergeinfo-cmd.o(.text+0x291):subversion/svn/mergeinfo-cmd.c:120: undefined reference to `svn_client_root_url_from_path'
mergeinfo-cmd.o(.text+0x380):subversion/svn/mergeinfo-cmd.c:153: undefined reference to `svn_client_mergeinfo_get_available'
mkdir-cmd.o(.text+0x17b): In function `svn_cl__mkdir':
subversion/svn/mkdir-cmd.c:77: undefined reference to `svn_client_mkdir3'
move-cmd.o(.text+0x1ef): In function `svn_cl__move':
subversion/svn/move-cmd.c:86: undefined reference to `svn_client_move5'
propdel-cmd.o(.text+0xad): In function `svn_cl__propdel':
subversion/svn/propdel-cmd.c:65: undefined reference to `svn_client_get_changelist'
propdel-cmd.o(.text+0x33b):subversion/svn/propdel-cmd.c:136: undefined reference to `svn_client_propset3'
propedit-cmd.o(.text+0x417): In function `svn_cl__propedit':
subversion/svn/propedit-cmd.c:179: undefined reference to `svn_client_propget4'
propedit-cmd.o(.text+0x722):subversion/svn/propedit-cmd.c:257: undefined reference to `svn_client_propset3'
propget-cmd.o(.text+0x464): In function `svn_cl__propget':
subversion/svn/propget-cmd.c:189: undefined reference to `svn_client_get_changelist'
propget-cmd.o(.text+0x8a4):subversion/svn/propget-cmd.c:294: undefined reference to `svn_client_propget4'
proplist-cmd.o(.text+0x1d4): In function `svn_cl__proplist':
subversion/svn/proplist-cmd.c:121: undefined reference to `svn_client_get_changelist'
proplist-cmd.o(.text+0x5ec):subversion/svn/proplist-cmd.c:224: undefined reference to `svn_client_proplist3'
propset-cmd.o(.text+0x1d5): In function `svn_cl__propset':
subversion/svn/propset-cmd.c:99: undefined reference to `svn_client_get_changelist'
propset-cmd.o(.text+0x4e9):subversion/svn/propset-cmd.c:203: undefined reference to `svn_client_propset3'
resolved-cmd.o(.text+0x1c1): In function `svn_cl__resolved':
subversion/svn/resolved-cmd.c:89: undefined reference to `svn_client_resolved2'
revert-cmd.o(.text+0x58): In function `svn_cl__revert':
subversion/svn/revert-cmd.c:52: undefined reference to `svn_client_get_changelist'
revert-cmd.o(.text+0x1b5):subversion/svn/revert-cmd.c:86: undefined reference to `svn_client_revert2'
status-cmd.o(.text+0x32a): In function `do_status':
subversion/svn/status-cmd.c:188: undefined reference to `svn_client_status3'
status-cmd.o(.text+0x3de): In function `svn_cl__status':
subversion/svn/status-cmd.c:224: undefined reference to `svn_client_get_changelist'
switch-cmd.o(.text+0x49c): In function `svn_cl__switch':
subversion/svn/switch-cmd.c:161: undefined reference to `svn_client_switch2'
unlock-cmd.o(.text+0x51): In function `svn_cl__unlock':
subversion/svn/unlock-cmd.c:53: undefined reference to `svn_client_get_changelist'
update-cmd.o(.text+0x51): In function `svn_cl__update':
subversion/svn/update-cmd.c:53: undefined reference to `svn_client_get_changelist'
update-cmd.o(.text+0x18d):subversion/svn/update-cmd.c:82: undefined reference to `svn_client_update3'
collect2: ld returned 1 exit status
2:
cd subversion/svn && /bin/sh /home/stsp/elego/svn-tigris/libtool --tag=CC --silent --mode=link gcc -g -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -L/usr/local/lib/db4 -L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb -lexpat -liconv /usr/local/lib/libapr-1.la /usr/local/lib/libneon.la
/home/stsp/elego/svn-tigris/subversion/libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0.0: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libsasl2.so.2.22: warning: sprintf() is often misused, please use snprintf()
/usr/local/lib/libsasl2.so.2.22: warning: strcat() is almost always misused, please use strlcat()
/usr/bin/ld: warning: libsvn_subr-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_subr-1.so.0.0
/usr/bin/ld: warning: libsvn_delta-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_delta-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_fs-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_base-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs_base-1.so.0.0
/usr/bin/ld: warning: libsvn_fs-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_repos-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_repos-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_local-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra_local-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_svn-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra_svn-1.so.0.0
/usr/bin/ld: warning: libsvn_ra-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_ra-1.so.0.0
/usr/bin/ld: warning: libsvn_diff-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_diff-1.so.0.0
/usr/bin/ld: warning: libsvn_wc-1.so.1.0, needed by /usr/local/lib/libsvn_client-1.so.1.0, may conflict with libsvn_wc-1.so.0.0
add-cmd.o(.text+0x167): In function `svn_cl__add':
subversion/svn/add-cmd.c:68: undefined reference to `svn_client_add4'
blame-cmd.o(.text+0x76c): In function `svn_cl__blame':
subversion/svn/blame-cmd.c:304: undefined reference to `svn_client_blame4'
changelist-cmd.o(.text+0x52): In function `svn_cl__changelist':
subversion/svn/changelist-cmd.c:55: undefined reference to `svn_client_get_changelist'
changelist-cmd.o(.text+0x26b):subversion/svn/changelist-cmd.c:106: undefined reference to `svn_client_add_to_changelist'
changelist-cmd.o(.text+0x2b3):subversion/svn/changelist-cmd.c:123: undefined reference to `svn_client_remove_from_changelist'
checkout-cmd.o(.text+0x34e): In function `svn_cl__checkout':
subversion/svn/checkout-cmd.c:159: undefined reference to `svn_client_checkout3'
commit-cmd.o(.text+0x1e4): In function `svn_cl__commit':
subversion/svn/commit-cmd.c:102: undefined reference to `svn_client_commit4'
copy-cmd.o(.text+0x2f1): In function `svn_cl__copy':
subversion/svn/copy-cmd.c:135: undefined reference to `svn_client_copy4'
delete-cmd.o(.text+0x181): In function `svn_cl__delete':
subversion/svn/delete-cmd.c:76: undefined reference to `svn_client_delete3'
diff-cmd.o(.text+0x4c3): In function `svn_cl(double, int, float, float)':
subversion/svn/diff-cmd.c:197: undefined reference to `svn_client_get_changelist'
diff-cmd.o(.text+0xb26):subversion/svn/diff-cmd.c:344: undefined reference to `svn_client_diff_summarize2'
diff-cmd.o(.text+0xbb2):subversion/svn/diff-cmd.c:356: undefined reference to `svn_client_diff4'
diff-cmd.o(.text+0xcaa):subversion/svn/diff-cmd.c:388: undefined reference to `svn_client_diff_summarize_peg2'
diff-cmd.o(.text+0xd3d):subversion/svn/diff-cmd.c:400: undefined reference to `svn_client_diff_peg4'
export-cmd.o(.text+0x19b): In function `svn_cl__export':
subversion/svn/export-cmd.c:79: undefined reference to `svn_client_export4'
import-cmd.o(.text+0x1e1): In function `svn_cl__import':
subversion/svn/import-cmd.c:115: undefined reference to `svn_client_import3'
info-cmd.o(.text+0xeae): In function `svn_cl__info':
subversion/svn/info-cmd.c:459: undefined reference to `svn_client_get_changelist'
info-cmd.o(.text+0x10fa):subversion/svn/info-cmd.c:523: undefined reference to `svn_client_info2'
list-cmd.o(.text+0x991): In function `svn_cl__list':
subversion/svn/list-cmd.c:284: undefined reference to `svn_client_list2'
lock-cmd.o(.text+0x141): In function `svn_cl__lock':
subversion/svn/lock-cmd.c:94: undefined reference to `svn_client_get_changelist'
log-cmd.o(.text+0x94b): In function `svn_cl__log':
subversion/svn/log-cmd.c:475: undefined reference to `svn_client_get_changelist'
log-cmd.o(.text+0xe18):subversion/svn/log-cmd.c:613: undefined reference to `svn_client_log4'
log-cmd.o(.text+0xf0e):subversion/svn/log-cmd.c:637: undefined reference to `svn_client_log4'
merge-cmd.o(.text+0x62e): In function `svn_cl__merge':
subversion/svn/merge-cmd.c:229: undefined reference to `svn_client_merge_peg3'
merge-cmd.o(.text+0x67f):subversion/svn/merge-cmd.c:244: undefined reference to `svn_client_merge3'
mergeinfo-cmd.o(.text+0x225): In function `svn_cl__mergeinfo':
subversion/svn/mergeinfo-cmd.c:109: undefined reference to `svn_client_mergeinfo_get_merged'
mergeinfo-cmd.o(.text+0x291):subversion/svn/mergeinfo-cmd.c:120: undefined reference to `svn_client_root_url_from_path'
mergeinfo-cmd.o(.text+0x380):subversion/svn/mergeinfo-cmd.c:153: undefined reference to `svn_client_mergeinfo_get_available'
mkdir-cmd.o(.text+0x17b): In function `svn_cl__mkdir':
subversion/svn/mkdir-cmd.c:77: undefined reference to `svn_client_mkdir3'
move-cmd.o(.text+0x1ef): In function `svn_cl__move':
subversion/svn/move-cmd.c:86: undefined reference to `svn_client_move5'
propdel-cmd.o(.text+0xad): In function `svn_cl__propdel':
subversion/svn/propdel-cmd.c:65: undefined reference to `svn_client_get_changelist'
propdel-cmd.o(.text+0x33b):subversion/svn/propdel-cmd.c:136: undefined reference to `svn_client_propset3'
propedit-cmd.o(.text+0x417): In function `svn_cl__propedit':
subversion/svn/propedit-cmd.c:179: undefined reference to `svn_client_propget4'
propedit-cmd.o(.text+0x722):subversion/svn/propedit-cmd.c:257: undefined reference to `svn_client_propset3'
propget-cmd.o(.text+0x464): In function `svn_cl__propget':
subversion/svn/propget-cmd.c:189: undefined reference to `svn_client_get_changelist'
propget-cmd.o(.text+0x8a4):subversion/svn/propget-cmd.c:294: undefined reference to `svn_client_propget4'
proplist-cmd.o(.text+0x1d4): In function `svn_cl__proplist':
subversion/svn/proplist-cmd.c:121: undefined reference to `svn_client_get_changelist'
proplist-cmd.o(.text+0x5ec):subversion/svn/proplist-cmd.c:224: undefined reference to `svn_client_proplist3'
propset-cmd.o(.text+0x1d5): In function `svn_cl__propset':
subversion/svn/propset-cmd.c:99: undefined reference to `svn_client_get_changelist'
propset-cmd.o(.text+0x4e9):subversion/svn/propset-cmd.c:203: undefined reference to `svn_client_propset3'
resolved-cmd.o(.text+0x1c1): In function `svn_cl__resolved':
subversion/svn/resolved-cmd.c:89: undefined reference to `svn_client_resolved2'
revert-cmd.o(.text+0x58): In function `svn_cl__revert':
subversion/svn/revert-cmd.c:52: undefined reference to `svn_client_get_changelist'
revert-cmd.o(.text+0x1b5):subversion/svn/revert-cmd.c:86: undefined reference to `svn_client_revert2'
status-cmd.o(.text+0x32a): In function `do_status':
subversion/svn/status-cmd.c:188: undefined reference to `svn_client_status3'
status-cmd.o(.text+0x3de): In function `svn_cl__status':
subversion/svn/status-cmd.c:224: undefined reference to `svn_client_get_changelist'
switch-cmd.o(.text+0x49c): In function `svn_cl__switch':
subversion/svn/switch-cmd.c:161: undefined reference to `svn_client_switch2'
unlock-cmd.o(.text+0x51): In function `svn_cl__unlock':
subversion/svn/unlock-cmd.c:53: undefined reference to `svn_client_get_changelist'
update-cmd.o(.text+0x51): In function `svn_cl__update':
subversion/svn/update-cmd.c:53: undefined reference to `svn_client_get_changelist'
update-cmd.o(.text+0x18d):subversion/svn/update-cmd.c:82: undefined reference to `svn_client_update3'
collect2: ld returned 1 exit status
*** Error code 1
Stop in /home/stsp/elego/svn-tigris (line 738 of ./build-outputs.mk).
3:
stsp@jack [svn-tigris] $ cd subversion/svn && /bin/sh /home/stsp/elego/svn-tigris/libtool --tag=CC --silent --mode=link gcc -g -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -o svn add-cmd.o blame-cmd.o cat-cmd.o changelist-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o conflict-callbacks.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mergeinfo-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb -lexpat -liconv /usr/local/lib/libapr-1.la /usr/local/lib/libneon.la -L/usr/local/lib/db4 -L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/lib
/home/stsp/elego/svn-tigris/subversion/libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0.0:
warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libsasl2.so.2.22: warning: sprintf() is often misused,
please use snprintf()
/usr/local/lib/libsasl2.so.2.22: warning: strcat() is almost always
misused, please use strlcat()
/usr/bin/ld: warning: libsvn_ra-1.so.1.0, needed by
../../subversion/libsvn_client/.libs/libsvn_client-1.so.0.0, may
conflict with libsvn_ra-1.so.0.0
/usr/bin/ld: warning: libsvn_wc-1.so.1.0, needed by
../../subversion/libsvn_client/.libs/libsvn_client-1.so.0.0, may
conflict with libsvn_wc-1.so.0.0
/usr/bin/ld: warning: libsvn_diff-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0.0,
may conflict with libsvn_diff-1.so.0.0
/usr/bin/ld: warning: libsvn_delta-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0.0,
may conflict with libsvn_delta-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_svn-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0.0,
may conflict with libsvn_ra_svn-1.so.0.0
/usr/bin/ld: warning: libsvn_ra_local-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0.0,
may conflict with libsvn_ra_local-1.so.0.0
/usr/bin/ld: warning: libsvn_repos-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0.0,
may conflict with libsvn_repos-1.so.0.0
/usr/bin/ld: warning: libsvn_fs-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0.0,
may conflict with libsvn_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_base-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0.0,
may conflict with libsvn_fs_base-1.so.0.0
/usr/bin/ld: warning: libsvn_fs_fs-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0.0,
may conflict with libsvn_fs_fs-1.so.0.0
/usr/bin/ld: warning: libsvn_subr-1.so.1.0, needed by
/home/stsp/elego/svn-tigris/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.so.0.0,
may conflict with libsvn_subr-1.so.0.0
stsp@jack [svn-tigris] $ ldd ./subversion/svn/.libs/svn
./subversion/svn/.libs/svn:
./subversion/svn/.libs/svn: can't load library 'libsvn_fs_util-1.so.0.0'
./subversion/svn/.libs/svn: exit status 4
libtool made its wrapper script:
stsp@jack [svn-tigris] $ file ./subversion/svn/svn
./subversion/svn/svn: Bourne shell script text
But it fails to run:
stsp@jack [svn-tigris] $ ./subversion/svn/svn
/home/stsp/elego/svn-tigris/subversion/svn/.libs/svn:/usr/local/lib/libsvn_fs_base-1.so.1.0:
/home/stsp/elego/svn-tigris/subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so.0.0
: WARNING: symbol(txn_vtable) size mismatch, relink your program
Type 'svn help' for usage.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: libtool issue
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Dec 05, 2007 at 01:41:30PM -0800, Justin Erenkrantz wrote:
> On Dec 5, 2007 2:57 AM, Joe Orton <jo...@redhat.com> wrote:
> > Subversion (unnecessarily) links executables using "-rpath $(libdir)",
> > so if you have old libraries in $(libdir) at build time it should be
> > expected that odd things will happen.
> >
> > I have previously argued that this is incorrect, and we've been fixing
> > it in the Fedora Subversion package for a long time, as below.
>
> Without -R, how would the resulting binary know where to find the
> shared libraries?
-R are -rpath are slightly different; -rpath has a specific meaning when
linking a library: "this is the installation directory", and is
equivalent to -R when linking an executable.
But the answer is: libtool *automatically* adds an RPATH when linking
against a library which is (or will be) installed in a non-system
directory. You do not have to explicitly request such RPATHs - this is
covered in the libtool manual:
http://www.gnu.org/software/libtool/manual.html#Linking-executables
e.g. every default install of httpd on any platform would not work, if
this were not the case.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Dec 5, 2007 2:57 AM, Joe Orton <jo...@redhat.com> wrote:
> Subversion (unnecessarily) links executables using "-rpath $(libdir)",
> so if you have old libraries in $(libdir) at build time it should be
> expected that odd things will happen.
>
> I have previously argued that this is incorrect, and we've been fixing
> it in the Fedora Subversion package for a long time, as below.
Without -R, how would the resulting binary know where to find the
shared libraries? Removing -R might work on Linux, but on Solaris, if
you omit the -R options, the run-time linker won't know where to find
the libsvn_* DSOs. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Dec 05, 2007 at 01:02:01AM +0100, Stefan Sperling wrote:
> Basically, anyone compiling subversion trunk on an ELF platform
> should have seen this, given that they also have a subversion package
> provided by the OS installed on their system. I know that it happens
> on Debian (confirmed by Karl), FreeBSD (run ldd on the binary to see
> crazy linkage), and OpenBSD (compile fails).
Subversion (unnecessarily) links executables using "-rpath $(libdir)",
so if you have old libraries in $(libdir) at build time it should be
expected that odd things will happen.
I have previously argued that this is incorrect, and we've been fixing
it in the Fedora Subversion package for a long time, as below.
--- subversion-0.31.0/build/generator/gen_base.py.rpath
+++ subversion-0.31.0/build/generator/gen_base.py
@@ -421,6 +421,9 @@
tfile = '%s-%s%s' % (name, cfg.version, extmap['lib', 'target'])
self.filename = os.path.join(self.path, tfile)
+ ### hmm. this is Makefile-specific
+ self.link_cmd = '$(LINK_LIB)'
+
class TargetApacheMod(TargetLib):
def __init__(self, name, options, cfg, extmap):
--- subversion-0.31.0/Makefile.in.rpath
+++ subversion-0.31.0/Makefile.in
@@ -127,7 +127,8 @@
COMPILE_SWIG_JAVA = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_JAVA_INCLUDES) $(INCLUDES) -o $@ -c
COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
+LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS)
+LINK_LIB = $(LINK) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Marcus Rueckert <da...@web.de>.
On 2007-12-07 08:23:38 -0600, Peter Samuelson wrote:
> [Stefan Sperling]
> > If this is really a bug in libtool, it is a major bug IMHO, making
> > libtool next to useless.
>
> If this is the same bug as the known one in Debian libtool, it does not
> render libtool "next to useless". It only manifests itself when you're
> linking an executable to an in-tree library which itself is linked to a
> second in-tree library, AND you also happen to already have a version
> of the second library in your system library location, AND the first
> library needs something from the second library which the system copy
> doesn't provide.
>
> It happens with Subversion, sure, but it isn't exactly a common case
> for libtool in general. By the way, the way I work around it in the
> Debian build scripts is just to throw an error if the user has the
> 'libsvn-dev' package installed on the build system. So you have to
> remove libsvn-dev before rebuilding svn. (In practice, installing and
> removing packages in order to auto-build a package is such a common
> case in Debian, and so easy to do anyway, that I doubt my workaround
> poses a serious inconvenience.)
or build inside clean chroots/VMs where you just install the stuff really
needed to build something. works very well for us.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Peter Samuelson <pe...@p12n.org>.
[Stefan Sperling]
> If this is really a bug in libtool, it is a major bug IMHO, making
> libtool next to useless.
If this is the same bug as the known one in Debian libtool, it does not
render libtool "next to useless". It only manifests itself when you're
linking an executable to an in-tree library which itself is linked to a
second in-tree library, AND you also happen to already have a version
of the second library in your system library location, AND the first
library needs something from the second library which the system copy
doesn't provide.
It happens with Subversion, sure, but it isn't exactly a common case
for libtool in general. By the way, the way I work around it in the
Debian build scripts is just to throw an error if the user has the
'libsvn-dev' package installed on the build system. So you have to
remove libsvn-dev before rebuilding svn. (In practice, installing and
removing packages in order to auto-build a package is such a common
case in Debian, and so easy to do anyway, that I doubt my workaround
poses a serious inconvenience.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Dec 5, 2007 12:37 AM, Stefan Sperling <st...@elego.de> wrote:
> If this is really a bug in libtool, it is a major bug IMHO,
> making libtool next to useless. Is the hassle with libtool
> really worth it? Have alternatives been examined? Are there any?
>
> As always though, venting alone does not help. I'll see if I can
> spend more time on this some day. Any help is appreciated.
Use jlibtool. (Hint: --enable-experimental-libtool to APR and SVN.)
It'll also compile *way* faster than GNU libtool and doesn't suffer
this brain damage. And, oh, welcome to the "I hate GNU libtool" club.
=) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Albert Chin <su...@mlists.thewrittenword.com>.
On Wed, Dec 05, 2007 at 09:37:18AM +0100, Stefan Sperling wrote:
> On Tue, Dec 04, 2007 at 07:16:54PM -0600, Peter Samuelson wrote:
> > [*] http://bugs.debian.org/291641. Both libtool and GNU ld have been
> > blamed as the root cause of this bug, which is exposed through a
> > libtool change. Nobody seems eager to step in and hack a
> > fix/workaround into libtool or ld, perhaps because both packages
> > are intimidating.
>
> :(
>
> So this is probably why -L flags still end up in between the
> working copy libraries on the ld command line.
I think Ralf (one of the libtool maintainers) has a patch to preserve
library order in libtool. It'll probably be added in libtool-2.1.
--
albert chin (china@thewrittenword.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool issue
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 04, 2007 at 07:16:54PM -0600, Peter Samuelson wrote:
> libtool goes to a lot of trouble to set library search paths while you
> compile and run your application, so that it uses libraries inside the
> build tree instead of system copies.
Does that mean "libtool tries to move all -L and -l flags for system
libraries to the end of the command line"? Because if I do that manually
the linking seems to work correctly.
After about 6 hours I had the subversion build system do just that
(I can send this as a patch to the list if it is interesting),
but libtool still kept putting working copy libraries after -L<system lib dir>
flags for some reason.
> This feature is known to be
> broken in Debian as a side effect of another more important libtool
> fix[*], but last I heard it worked fine on other platforms. I guess it
> is possible that libtool is broken everywhere now for some reason. It
> always was a difficult feature to support properly.
Looks like it.
> [*] http://bugs.debian.org/291641. Both libtool and GNU ld have been
> blamed as the root cause of this bug, which is exposed through a
> libtool change. Nobody seems eager to step in and hack a
> fix/workaround into libtool or ld, perhaps because both packages
> are intimidating.
:(
So this is probably why -L flags still end up in between the
working copy libraries on the ld command line.
And this is also why people should not write 8000+ lines long
shell scripts...
If this is really a bug in libtool, it is a major bug IMHO,
making libtool next to useless. Is the hassle with libtool
really worth it? Have alternatives been examined? Are there any?
As always though, venting alone does not help. I'll see if I can
spend more time on this some day. Any help is appreciated.
Thanks,
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: libtool issue
Posted by Peter Samuelson <pe...@p12n.org>.
[Stefan Sperling]
> Is there a particular reason why library versioning isn't already
> being done?
Library versioning is somewhat complex, but the part we care about here
is the ABI label, which on ELF is called the "SONAME" (shared object
name). This is a string that takes the form "libsvn_wc-1.so.0", and
libtool builds this string from -version-info. On the installed system
the same string will exist as a symlink to the appropriate library
implementing this interface, and that's how the ELF runtime linker
finds it. The runtime linker doesn't care what the string is or what
it looks like, except to look for it as a filename (usually a symlink).
Until libsvn_* change their ABI in an incompatible way, it is not
appropriate to change the SONAMEs. Such changes will not be done for
any Subversion 1.x. (Well, except that some people now want to
officially recommend building libsvn for use with Apache 2.2, which
would probably cause memory corruption crashes in applications which
are not recompiled, but that change is not tied to a specific svn
release.)
libtool goes to a lot of trouble to set library search paths while you
compile and run your application, so that it uses libraries inside the
build tree instead of system copies. This feature is known to be
broken in Debian as a side effect of another more important libtool
fix[*], but last I heard it worked fine on other platforms. I guess it
is possible that libtool is broken everywhere now for some reason. It
always was a difficult feature to support properly.
[*] http://bugs.debian.org/291641. Both libtool and GNU ld have been
blamed as the root cause of this bug, which is exposed through a
libtool change. Nobody seems eager to step in and hack a
fix/workaround into libtool or ld, perhaps because both packages
are intimidating.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/