Re: can one make a static build Ada+GUI GTK application?

["Björn Persson" <bjorn@xn--rombobjrn-67a.se>]

Randy Brukardt wrote:
> I don't think it is a good idea to link to anything other than things that 
> are always distributed with the OS. (That opinion probably doesn't work as 
> well on Linux as it does on Windows, where the standard distributions 
> contain pretty much everything you'll need).

That's not how it looks from my point of view. It's the big free
software distributions that contain pretty much everything you'll need,
lots more than Windows contains. There are all sorts of network servers
and clients, peer-to-peer programs, office suites, graphics editors,
audio editors, games, lots of development tools – and of course all of
the libraries that all of those programs use.

There's no need to reinvent wheels just to avoid libraries that might
not be installed. The package manager will install the required
libraries if they aren't already installed, so although nobody has the
entire distribution installed you don't need to worry about that. (Each
of the big distributions is built around a package manager, for example
Yum or APT. Each package has a list of other packages that it depends
on, and the package manager resolves the dependencies automatically.)

If the program you're packaging requires some library that isn't
packaged yet (like for example some Ada library, as there aren't many
of those packaged), then you simply package that library too – in a
package of its own.

> The problem being that as soon 
> as you depend on 3rd-party libraries (and *especially* dynamically-linked 
> 3rd party libraries), you've lost all control over the interface and 
> operations.

We have sonames and versioned symbols to help us control interfaces,
and package managers use them to ensure that installed packages are
compatible. It is possible to make mistakes though, and sometimes
developers forget to bump the soname when they make ABI changes.

As for operations, there is of course no way to guarantee that the
library actually works as documented – not even if you write it
yourself. :-)

> And you've also greatly complicated your installation and 
> updating requirements.

I suppose that's true in Windows. In Fedora, "yum install niftyprogram"
downloads and installs Nifty Program and all the libraries it needs.
"yum update" updates all installed packages to the latest version. Not
complicated at all. Other distributions have similar commands, and
there are also GUI tools for those who want that.

> It's certainly important that you *don't* statically link things that are 
> (or should be) part of the core OS. My brief experience with Linux is that 
> it makes this far more complicated than necessary

You will certainly run into problems if you try to draw a line between
which libraries are part of the "core OS" and which aren't. If you are
in the camp that equates "operating system" with "kernel", then it's
easy: The kernel is the operating system; programs and libraries
are not (although maybe a microkernel could make it more complicated).
If you are in the camp that wants to define "operating system" to
include more than a kernel, then there is no obvious place to draw the
line. Some components are more essential than others, but they don't
naturally fall into two categories. In Windows you could perhaps say
that what you get when you buy Windows is the operating system and
programs that you buy separately are add-ons. Applying that reasoning to
free software distributions would lead to defining the operating system
as the entire distribution. Fedora, Debian and others include lots of
games, toys and rather specialized utilities, and counting all of those
as parts of the operating system would be silly.

I have found it best not to think about anything as "the operating
system". Fedora is a software distribution, Linux is its kernel, and
what packages I install on a particular box depends on what I want that
box to do.

> (having a whole bunch of different GUI toolkits)

It definitely wouldn't make sense to declare that GTK+ is part of the
operating system and QT is an add-on, or the other way round. Choose
one that you like, link dynamically to it, and let your package depend
on the appropriate sonames.

> no Linux programmer 
> can assume that anything exists on another's system, even basic support.

If you distribute your program as an RPM (or .deb) package, then you can
assume that Yum (or APT) will install any libraries and other packages
it depends on.

Björn Persson