ports/134743: devel/Monotone and pthreaded dependencies

[Eir Nym]

The following reply was made to PR ports/134743; it has been noted by GNATS.

From: Eir Nym <eirnym at gmail.com>
To: Lapo Luchini <lapo at lapo.it>
Cc: bug-followup at freebsd.org
Subject: Re: ports/134743: devel/Monotone and pthreaded dependencies
Date: Tue, 16 Jun 2009 19:04:59 +0400

 SQLite application and library are thread-safe. I know about threading
 model in monotone, but I use SQLite in threaded envirounment, so I
 don't want have 2 versions of SQLite library to use monotone and some
 other.
 
 `mtn --version;ldd /usr/local/bin/mtn` says
 
 monotone 0.44 (base revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
 /usr/local/bin/mtn:
 	libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28446000)
 	libbotan-1.6.5.so => /usr/local/lib/libbotan-1.6.5.so (0x28475000)
 	liblua-5.1.so.1 => /usr/local/lib/liblua-5.1.so.1 (0x286f1000)
 	libm.so.5 => /lib/libm.so.5 (0x28716000)
 	libsqlite3.so.8 => /usr/local/lib/libsqlite3.so.8 (0x28730000)
 	libidn.so.16 => /usr/local/lib/libidn.so.16 (0x287b0000)
 	libz.so.4 => /lib/libz.so.4 (0x287e0000)
 	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x287f2000)
 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x288e6000)
 	libc.so.7 => /lib/libc.so.7 (0x288f1000)
 	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28a04000)
 
 
 On Tue, Jun 2, 2009 at 2:22 AM, Lapo Luchini <lapo at lapo.it> wrote:
 >
 > > When I build boost or sqlite threaded, monotone will crash with core dump.
 >
 > I think the problem can only be against a threaded SQLite, as Boost is
 > not linked against: only parts that are needed are headers-only and I
 > guess that doesn't justify the need for -pthread (does it?).
 >
 > Monotone is single-threaded and up to 0.42 used to (include in the
 > tarball and) statically link all the needed libraries in a un-threaded
 > form. Then was made the (sensible, IMHO) choice to use system libraries
 > and problems such as this can arise.
 >
 > I'd like to investigate the matter a little bit further before proposing
 > a solution, but if anyone knows multi-thread issues better, feel free to
 > suggest ;)