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

["Randy Brukardt" <randy@rrsoftware.com>]

"Dirk Heinrichs" <dirk.heinrichs@altum.de> wrote in message 
news:kgadoj$ihm$1@online.de...
> Nasser M. Abbasi wrote:
>
>> If I do such an app, and send it to someone,
>> I'd like them to be able to run it on their PC
>> without having to install anything on their end.
>
> Hmm, thought static linking was a thing of the past, because of it's
> possible security problems.

"Linking" in general is a bad idea, one that needs to be limited to very 
specific things.

> If one of your statically linked libs has a security flaw, it can't be
> exchanged easily. You must relink and resend your binary to get the fixed
> version to the receiver of your program.

Certainly true, but...

> If, OTOH, you just tell the receiver to install libraries X, Y and Z to be
> able to run your program, nether you nor him need to worry about missed
> security fixes. All you need to to is to replace the vulnerable version of 
> a
> shared lib with the fixed one.

...if you have to tell users to "update" something, you're already dead 
(there's no way that most of them will do that). You have a better chance 
updating them yourself (as part of your own patch).

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). 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. And you've also greatly complicated your installation and 
updating requirements. [And all code not written in Ada is junk. ;-) TM]

With Claw, we only allowed interfacing to OS facilities, for which there is 
a fairly well-defined interface. Those interfaces caused a large percentage 
of the bugs that we had (either because we had gotten wrong or because the 
documentation didn't reflect reality). Those facilities of course get 
updated on their own schedule, and in most cases, problems with them are not 
something that we could do anything about. In the cases where the interface 
itself is the problem, we'd have to rebuild the application either way (a 
broken interface is going to stay broken no matter how the underlying 
linking is done).

Beyond that, we insisted on having all other code in Ada. That prevents most 
security problems simply by having the strong checking that an Ada compiler 
provides, and it also opens up the possibility using more extensive analysis 
on the entire code-base (like CodePeer). Ada 2012 provides ways to 
strengthen the interfaces a bit, but since you have no real idea what the 
other side does, it's not a real help.

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 (having a whole bunch of 
different GUI toolkits), and the real problem is there: no Linux programmer 
can assume that anything exists on another's system, even basic support. 
Which leads toward those bad choices between static and dynamic linking.

(If Janus/Ada ever became available for Linux, it would be self-contained, 
only requiring the kernel to run. It of course would optionally support 
linking with other stuff, but there would be no requirement to do so. This 
is how it worked on MS-DOS, Unix, Sun OS, and other systems in the past --  
we didn't do that for Windows mainly because we couldn't find enough 
information back in the Windows NT days to implement that. And there never 
was much demand for a better way there.)

                                                       Randy.