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,UTF8 X-Received: by 10.180.93.230 with SMTP id cx6mr722759wib.5.1362276833583; Sat, 02 Mar 2013 18:13:53 -0800 (PST) Path: bp2ni69216wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.139.MISMATCH!xlned.com!feeder7.xlned.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: =?UTF-8?B?QmrDtnJu?= Persson Newsgroups: comp.lang.ada Subject: Re: can one make a static build Ada+GUI GTK application? Date: Thu, 28 Feb 2013 01:00:57 +0100 Message-ID: <20130228010057.13659976@hactar.xn--rombobjrn-67a.se> References: Mime-Version: 1.0 X-Trace: individual.net GDAUfAr//Nhv3ejqdkSxxQzRyJia3vVq0zWiXzOMKP+y48tUvHbJlW/9zNjfaeZFxG Cancel-Lock: sha1:w9uxd3R6qG3eM+WpGRZPxlRtNac= X-Newsreader: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: 2013-02-28T01:00:57+01:00 List-Id: Randy Brukardt wrote: > I don't think it is a good idea to link to anything other than things tha= t=20 > are always distributed with the OS. (That opinion probably doesn't work a= s=20 > well on Linux as it does on Windows, where the standard distributions=20 > 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 =E2=80=93 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 =E2=80=93 in a package of its own. > The problem being that as soon=20 > as you depend on 3rd-party libraries (and *especially* dynamically-linked= =20 > 3rd party libraries), you've lost all control over the interface and=20 > 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 =E2=80=93 not even if you write it yourself. :-) > And you've also greatly complicated your installation and=20 > 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= =20 > (or should be) part of the core OS. My brief experience with Linux is tha= t=20 > 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=20 > 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=C3=B6rn Persson