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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
