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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: More reliable compilers (of some programming langauges) than GNAT Date: Tue, 28 Nov 2017 10:24:56 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2fca0f38-833e-485d-9a38-febcdd507bb1@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:49213 Date: 2017-11-28T10:24:56+01:00 List-Id: On 28/11/2017 02:09, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:ov60fj$mt8$1@gioia.aioe.org... >> On 23/11/2017 01:35, Randy Brukardt wrote: > ... >>> as they are a rather useless construct that mainly serves to >>> introduce bugs (if the shared library gets updated out of sync with >>> the rest of the program). >> >> There is no any alternative to shared libraries. > > Of course there is: write your code to use nothing but the target OS > facilities and Ada. (Yes, I know that Windows uses shared libraries to > implement the OS interface, but that's not visible to a statically linked > program.) That was always the requirement at RRS, and any time that we've > deviated from it we've generally come to regret it. It does not work for any services, which stretch far beyond core OS. Basically if we were in 60's and everything would be standard I/O, you could ditch shared libraries, but now practically nothing is read/write/ioctl, but a call to some entry point in some shared library. > Statically linked programs are not going to fail because of some upgrade > outside of botched OS upgrades (which are much less likely than other kinds, > because most OS vendors are well aware of the havoc that they can cause). If somebody changes the parameters of ioctl or position where you read from or contents of the read data, your application will fail just the same. It is no matter how an interface to some external entity looks like. If the interface changes or if the external entity changes, you have a problem. Shared libraries provide much better interfaces than I/O. So they won, which is a good thing. > The supposed reasons for using shared libraries rarely hold any water (there > aren't going to be dozens of nearly identical Ada programs running on a > single machine at a single time). This applies only to pure computational components which are in minority and usually quite stable, because there is little reason why you would change interface of some solver. The majority of shared libraries is a combination of computations with some "monitor" part dealing with the outer world. You cannot have it static, it is impossible because of the second part. You could try to separate computation from the monitor, but that does not really work. E.g. GTK started as a separation of computational GUI from X11 I/O. Then it became an I/O itself and you have the same old problem again. Unless you pack everything into the OS and hold it there, you have no chance. The last who did that was DEC, long gone and dead. (DEC systems had perfect shared libraries too.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de