Re: [Vala] Static linking

[Jan Hudec <bulb ucw cz>]

On Thu, Dec 03, 2009 at 02:00:48 -0700, Mark Dewey wrote:
> Jan Hudec wrote:
> > First thing I should make really clear is, that if you want to link program
> > P against library L statically or dynamically, you compile the program P
> > the *same* way against *differently compiled library L*.
> > …
> Thanks for the thorough reply! Linking sounds like it can be a lot of
> work at times, but it's good to have some more reference about it.

You are welcome.

> […] (is there a way to get a program in Linux
> to look for .so files there, out of curiosity?)

There are basically two ways:

 - rpath: It is possible to define at linktime additional directory to look
   for shared libraries. Unfortunately binary-relative paths are not
   supported.

 - LD_LIBRARY_PATH: Wrap the binary in a simple shell script, that sets (and
   exports) LD_LIBRARY_PATH environment variable set to the desired library
   directory (aboslute path) and execs the real binary. Basically

    #!/bin/sh
    export LD_LIBRARY_PATH=$(dirname -- "$0"):$LD_LIBRARY_PATH
    exec "$0.real"

   should do the trick (assuming the program has the same name as the script
   plus ".real" extension).

   You can do slightly more advanced tricks like having the script in
   directory 'bin' and the rest in directory 'lib' in the same parent:

    #!/bin/sh
    get_libdir() ( cd "$(dirname -- "$0/../lib")"; pwd; )
    libdir=$(get_libdir)
    export LD_LIBRARY_PATH="$libdir:$LD_LIBRARY_PATH"
    exec "$libdir/program.real"

   (program is the name of your program -- could read it from $0, but makes
   no sense)

> I don't really have too much against the normal way for Linux, except that
> about updates.

Gtk generally does pretty good job with the updates. It has to, since all of
gnome depends on it and all distributions always link dynamically. Besides
all users probably will have it installed anyway. So libgee is primary
concern, though I think it will be done very carefully too. Vala actually
makes it reasonably easy to maintain the ABI compatibility, since it only
exposes the really necessary stuff (contrary to C++, which makes maintaining
ABI compatibility a pain).

> How do Macs work in that regard? I know on a Mac you can get Vala through
> Darwin, but, you don't need Darwin to run the Vala programs, do you?
> It's not the end of the world, if so, but I'd rather it not be that way.

I don't use Mac. But from what I understood applications are distributed in
"bundles" there that the system just unpacks somewhere and they contain all
the data. I suppose they can contain necessary shared libraries too.

> Are there any libraries commonly used in Vala that aren't compatible
> with GNU GPLv3? Please tell me Gtk is fine there.

Most of them (inluding whole Gtk and whole Gnome stack and Gee) are
LGPL-2.1+, so they are fine. Note, though, that LGPL-2.1 without the "or, at
your option, any later version" would be a problem, because GPL-2 and GPL-3
are not compatible.

Regards,
Jan

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>