Re: Librsvg 2.41.0 is released
- From: Michael Catanzaro <mcatanzaro gnome org>
- To: Adrian Perez de Castro <aperez igalia com>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Librsvg 2.41.0 is released
- Date: Mon, 09 Jan 2017 15:14:01 -0600
On Fri, 2017-01-06 at 05:25 +0200, Adrian Perez de Castro wrote:
Could you elaborate on what's the issue with gtk-rs? The way things
work, the
code from it will be statically linked into librsvg, and if librsvg
uses
actual {GTK+,GLib,cairo} functions, then librsvg links *dynamically*
to
lib{gtk+,glib,cairo} (the ones made in C) as it would do anyway
before when
Rust wasn't used. Only the glue bits from gtk-rs which allow to use
the
libraries from Rust are linked into librsvg. Honestly, I fail to see
how this
is a problem.
The problem is that our distributors expect or require that
applications dynamically link to libraries. I would not expect gtk-rs
to be an exception to this rule.
On Fri, 2017-01-06 at 05:25 +0200, Adrian Perez de Castro wrote:
I also don't agree that Flatpak makes static linking acceptable for
librsvg, because librsvg is a very important platform library and
part
of our GNOME runtime. We're probably going to want to have gtk-rs
in
the runtime sooner or later to promote Rust development, right?
Surely
we're not going to want two different copies of it there.
Wrong. The way things are, gtk-rs is only needed at build time.
If it's statically linked into librsvg, then there's one copy of it for
each library in the runtime that wants to use it. In five years the
runtime would wind up with several different copies of gtk-rs. This
would be a problem.
Is there some real obstacle to dynamic linking, like a normal Linux
library? This is already supported and works fine, right...?
Michael
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]