On Mon, Mar 2, 2009 at 10:26 AM, Philip Martin <philip_at_codematters.co.uk> wrote:
> In the past this was:
>
> SVN_LIBTOOL="\$(SHELL) $sh_libtool"
>
> and it seems that on my box I need to use
>
> --with-custom-libtool='/bin/bash /usr/bin/libtool'
>
> because /usr/bin/libtool starts #!/bin/sh which on my box is dash and
> that doesn't support the += construct. Can we put the $SHELL back in?
Well, it shouldn't be unconditional as jlibtool is a binary and
supposedly future versions of GNU libtool are supposed to be
binary-only too. *sigh* This seems like a really bad bug in GNU
libtool. (Die libtool die.)
I'm open to suggestions, but I'm just not sure how to proceed here...
> Another problem is I now get lots of warning like:
>
> libtool: link: warning: `/usr/lib//libsqlite3.la' seems to be moved
>
> Note the double slash. This problem propogates into the final
> Subversion .la files so in libsvn_client-1.la, for example, the
> dependency_libs line contains /usr/lib//libsqlite3.la with a double
> slash whereas in the past it was a single slash. I guess this may
> introduce link warnings for people using the Subversion libraries. If
> I configure to use APR's libtool the warnings change to things like:
>
> libtool: link: warning: `/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib//libsqlite3.la' seems to be moved
>
> The old system didn't produce these warnings.
How does the build refer to libsqlite3.la? But, I don't think this is
directly caused by my changes - but rather some other bug is now
rearing its ugly head. *sigh* As Greg has said, this has been around
for *years*.
> Finally if I configure with --disable-static and I don't use
> --with-custom-libtool then the build fails. It seems to compile and
> link both shared and non-shared libraries, but linking executables
> fails with:
>
> cd subversion/svn && /usr/share/apr-1.0/build/libtool --tag=CC --silent --mode=link gcc -shared -g -DAPR_POOL_DEBUG -std=c89 -Wpointer-arith -Wdeclaration-after-statement -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wwrite-strings -Wbad-function-cast -pthread -DSVN_DEBUG -DAP_DEBUG -rpath /usr/local/subversion/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 resolve-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o tree-conflicts.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/lib/libaprutil-1.la /usr/lib/libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl -lneon
> /usr/bin/ld: add-cmd.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> add-cmd.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
>
> Is that supposed to work? If not can we make --enable-{shared,static}
> depend on --with-custom-libtool?
What flags were passed when compiling add-cmd.o? -prefer-pic (if
/usr/share/apr-1.0/build/libtool is 1.5.x) or -shared (if 2.x)? Both
should be setting -fPIC at compile time as long as libtool isn't
further brain-damaged. If you can please emit the compile line (ie
remove --silent) when add-cmd.o is compiled, that could be helpful.
(I'm assuming of course that you did a make clean of everything in
between switching shared/static builds.) -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1258672
Received on 2009-03-03 00:14:45 CET