Re: [Monotone-debian] monotone-viz FTBFS

[Francis Russell]

On 14/05/14 20:14, Ludovic Brenta wrote:
> Markus Wanner <address@hidden> writes:
>> On 05/14/2014 10:04 AM, Francis Russell wrote:
>>> I'm looking at this, but I've but yet been able to replicate. The build
>>> log for the failure seems to show everything fine except linking against
>>> the utility library. I'm guessing this may just be the search path for
>>> the linker isn't including the library, but I'll need to either work out
>>> what's causing this or create a Debian unstable installation first.
>>
>> thm on IRC just pointed out to me that linking against lib3rdparty.a
>> (which is also generated) might work. And it did for me.
>>
>> However, I'm not sure that's the right approach for the Debian package.
> 
> Either lib3rdparty.so is packaged separately and used in other software,
> in which case monotone should build-depend on it and not built it at
> all; or, lib3rdparty is a monotone-only construct, in which case
> monotone should only build the static version; better yet, do not build
> it at all as a library and link the constituent object files directly
> into the "mtn" executable.
> 
> The name suggests that "lib3rdparty" in fact contains software that is
> not part of monotone; in this case the Debian package for monotone
> should not build it at all and instead build-depend and link with the
> corresponding libraries (plural).
> 

Please note we're discussing monotone-viz, not mtn.

The libthirdparty.so is a utility library only used by monotone-viz. The
library is placed in /usr/lib/monotone-viz for this reason. IIRC, it's
so named since it contains some OCaml Glib bindings but existing
packaged bindings were (are?) too incomplete for monotone-viz's needs.

The library is dynamically linked due to this bug
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549463) which
incidentally was one I fixed when I updated the monotone-viz package a
while back. I'm afraid I forget the specifics, but I believe the package
works this way due to needing to support both platforms for which an
OCaml native compiler is or is not available. When a native code OCaml
compiler is not available, I believe static linking of the helper
library may be impossible in the latter case since there is no normal
executable to link to.

Francis