From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,fc2b5af8782d4ca3 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.8.4 with SMTP id n4mr2963631wia.0.1362421413536; Mon, 04 Mar 2013 10:23:33 -0800 (PST) MIME-Version: 1.0 Path: bp2ni72442wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.86.MISMATCH!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.thorslund.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: can one make a static build Ada+GUI GTK application? Date: Mon, 25 Feb 2013 17:25:35 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1361834736 12624 69.95.181.76 (25 Feb 2013 23:25:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 25 Feb 2013 23:25:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-02-25T17:25:35-06:00 List-Id: "Dirk Heinrichs" 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.