Libraries are being linked dynamically

[oakes]

While Rust is supposed to link libraries statically, it appears that rgtk programs use dynamic linking. When I compile the example projects and run otool -L target/treeview on OS X, I get the following:

target/treeview:
    /usr/local/lib/libgtk-3.0.dylib (compatibility version 1401.0.0, current version 1401.6.0)
    /usr/local/lib/libgdk-3.0.dylib (compatibility version 1401.0.0, current version 1401.6.0)
    /usr/local/lib/libpangocairo-1.0.0.dylib (compatibility version 3601.0.0, current version 3601.7.0)
    /usr/local/lib/libpango-1.0.0.dylib (compatibility version 3601.0.0, current version 3601.7.0)
    /usr/local/lib/libatk-1.0.0.dylib (compatibility version 21410.0.0, current version 21410.1.0)
    /usr/local/lib/libcairo-gobject.2.dylib (compatibility version 11203.0.0, current version 11203.16.0)
    /usr/local/lib/libcairo.2.dylib (compatibility version 11203.0.0, current version 11203.16.0)
    /usr/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 3001.0.0, current version 3001.8.0)
    /usr/local/opt/glib/lib/libgio-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.1.0)
    /usr/local/opt/glib/lib/libgobject-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.1.0)
    /usr/local/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.1.0)
    /usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.3.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

[gkoz]

Rust is supposed to link libraries statically

Is it?

Is there a particular problem you're solving?

[oakes]

Yes, it links rust libraries statically, so I expect native libraries to link the same way by default. I would rather not require users to install libraries before using my program.

[oakes]

Is there at least a way to opt into static linking? I've asked on IRC and everyone seems stumped.

[gkoz]

I suppose you could play with build.rs of each sys crate so it would emit instructions to link statically (and remove the link line from Cargo.toml). And tweak the lib line for the rgtk crate.
Or research how people bundle dynamic libraries with their apps on OS X.

[oakes]

It looks like dynamic linking is the intended default so I will close this, but I do think static linking is ideal for end-user programs (which rgtk is certainly relevant for).

[gkoz]

For the record, linking GTK statically is discouraged and almost nobody does it. So if relying on a package manager is a problem, you should look into bundling the libraries. You could also make a brew 'bottle', a deb package, etc so the dependencies wouldn't have to be handled manually.

[oakes]

Fair enough, I think that is a reasonable solution.

On Tue, Mar 10, 2015 at 7:33 AM, Gleb Kozyrev notifications@github.com
wrote:

For the record, linking GTK statically is discouraged and almost nobody
does it. So if relying on a package manager is a problem, you should look
into bundling the libraries. You could also make brew 'bottle', a deb
package, etc so the dependencies wouldn't have to be handled manually.

Reply to this email directly or view it on GitHub
#232 (comment).

[csoriano1618]

Also if at some point you want this inside a SDK of Gnome with Alex work on xdg-app you need this library to be dinamically linked to gtk+ etc.
What you want is a SDK, to avoid the users to manually install other libraries. Not this library being some sort of a part of a SDK =)