Philip Martin <philip@codematters.co.uk> writes:
> mailing.lists@gmx.net (SVN List) writes:
>
>> % cd subversion/clients/cmdline && /bin/bash
>> /shared/misc/software/sources/subversion-0.28.1/libtool --mode=link gcc
>> -g -O2 -pthreads -DNEON_ZLIB
>
> Here we have -pthreads in the libtool command...
>
> [...]
>> gcc -g -O2 -DNEON_ZLIB -o .libs/svn add-cmd.o cat-cmd.o checkout-cmd.o
>
> but it appears to have been dropped from the gcc command, I don't know
> why that happens. It also happens on my Linux box so it's not Solaris
> specific. However on my Linux box the apr library does get linked
> with -pthreads, and so when the executables link against libapr they
> pick up the thread library that way. I don't understand what libtool
> is doing.
>
> Does the link work if you run the gcc link command by hand and
> explicitly add a -pthreads flag?
I think it's a Debian specific problem. I'm using Debian's 1.4.3-10
package of libtool and it includes a patch to ltmain.in
http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz
and one of the things it does is
@@ -1200,6 +1211,11 @@
continue
;;
+ -Kthread | -mthreads | -mt | -pthread | -pthreads | -threads | -qthreaded | -kthread )
+ compiler_flags="$compiler_flags $arg"
+ continue
+ ;;
+
I don't pretend to understand the libtool script, but I think this
means libtool will only pass -pthread to compile commands, not to link
commands. If I remove those lines from the generated libtool file
then libtool will pass -pthread through to gcc link command.
I believe Paul uses Debian which would explain why the tarball has the
same behaviour. It would also explain the report that HEAD builds
even when the tarball fails, since anyone building HEAD will run
autogen and get their own version of libtool.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 1 20:10:56 2003