Re: [Vala] Static linking

["Jan Hudec" <bulb ucw cz>]

On Thu, December 3, 2009 03:30, Mark Dewey wrote:
> Jan Hudec wrote:
> > On Wed, Dec 02, 2009 at 04:52:13 -0700, Mark Dewey wrote:
> > > How do I statically link libraries for Vala programs? I mean, like
> > > libgee and such. Don't worry, I do plan to have a license compatible
> > > with such behavior.
> >
> > Well, just as you would any other C library.
>
> I have no idea how to link (either statically or dynamically) any other
> C library—that's why I posted. I'm having a very hard time finding
> anything that says how, too.

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*.

So you will need to get the library you want to link statically against
(libglib, libgee and maybe some others) to compile statically. Since these
libraries use autotools to build, you should be able to give options
to their configure scripts to compile them statically. I believe it is
--enable-static to enable creation of static variant and --disable-shared
to disable the dynamic one, but check with help (./configure --help).

However if you use gio (part of glib), be aware that it uses modules,
which are dynamic libraries anyway and you may not be able to do away
with that. So if you need Gtk+ (which does use gio), you are mostly out
of luck anyway.

> Also, valac -c doesn't seem to output the object files I would need. It
> just produces binaries, the same as without it. Is there something I'm
> missing?

valac will never give you objects. It will give you C sources, the option
is I belieive -C (check with help). Than you'll have to use a build tool
to compile and link them, but personally I'd do that in any case.

However, you don't want to create a library, you want to link against one,
right? So you don't really need that.

(For build tool, I found waf (code.google.com/p/waf) to be simple and
reasonable for compiling vala or you can use autotools, which are much
more complicated, but support more ancient, broken, exotic systems)

> If you're wondering why I want to do static linking, I have several
> reasons:
> • It's less work for the end user to use my program

If you are going to distribute the binary to systems, that don't have
the libraries not a decent package manager *AND* your program is
otherwise a self-contained binary, yes. If it's not, than

> • I need my program to be cross-platform, and other platforms besides
> Linux don't always have such a nice package system. Getting an every day
> Windows user to deal with that stuff just isn't very likely.

Windows look up dynamic libraries in the directory the binary is in,
so on windows it is exactly equivalent for the user. Besides, as I said,
Gtk+ probably won't work on Windows without installation anyway, so if
you need it, you'll have to create an installer and embed the Gtk+ installer
in it anyway.

> • I /don't/ want my packages automatically updated in the first place,
> unless I can be absolutely sure the updates won't cause problems. I'd
> rather deal with the updates manually. From my experience, too high of a
> percentage of the updates make the program so it doesn't work, without
> some kind of change or workaround. I want some kind of guarantee that my
> program will work exactly as it does now ten years from now if I decide
> to leave off development. I've seen this problem tons and tons with
> programs I've wanted to use, but for some reason or other, some change
> made it incompatible with the program.
>
> Anyway, whatever the case, I still need to know how to link. It's
> something any programmer should know, methinks.

Indeed. But I really suggest you start from some build tool and than
look at the compiler invocation it generates and look up what the
various options mean if you want to.

Basically, the workflow is

.vala -(valac)-> .c -(gcc)-> .o -(gcc or ld)-> (binary, extensionless)|
                                -(gcc or ld)-> .so.?.? (shared library)
                                -(ar)-> .a (static library)

gcc or ld means, that you can either the ld (linker) directly, or call
gcc which will simply call the linker, which is a bit easier, as you can
pass the same options as for compilation and gcc will translate or ignore
them as appropriate. Linking shared library requires -fpic at *compilation*
time and -shared at link time, IIRC, but check the manuals.

The ? in .so.?.? are the version numbers. The linked program knows the
first one and will only use library with that given first number. So
when incompatible changes are made, that number is incremented and old
programs don't use the new incompatible library.

-- 
                                        - Jan Hudec <bulb ucw cz>