Trying to understand program/app start-up methods...

[Mike Walsh]

Evening, all.

I've got a query; about summat I've been mulling over for a while now. I'm not certain this is even the right place to ask, but, here goes anyway.....

----------------------------------------------------------

As somebody who's been 'packaging' for a while, I'm used to the complete business of compiled binaries, shared libs (aka dependencies), desktop entries, config files.....the whole shebang. I'm trying to understand why it is that different progs & apps seem to start in different ways.

A compiled, executable 'binary' is easy enough to figure out. So long as everything it needs is in place, it doesn't matter whether you start it from a .desktop file, a script of some kind, even clicking directly on the binary itself.....the application will start.

Where I'm coming a wee bit unstuck is the area of 'wrapper-scripts'. I've used 'em for long enough; the Chromium-based browsers spring to mind here. (I installed the Kdenlive video editor into a fresh install of Tahr 606 this evening, and noticed the same thing...)

The 'bulk' of the program is in one huge, 'shared library'. You can't start it by 'clicking' on it directly; Pup assumes you want to check dependencies, and up comes 'list-dd'. But you start it from the terminal, or via a wee script, specifying the full path to the 'shared library'.....and it'll start up straightaway, just as though you've clicked on a binary executable.

Why is that? Dead curious, I am...! Just wondered if anybody had any pearls of wisdom, or observations to dispense with regard to this.....or, even better still, an understanding of the actual 'mechanics' behind this.

The Mozilla-based browsers seem to be a hybrid exception to the rule. The bulk of FF/PaleMoon/SeaMonkey/'Light'/whatever, lies in a single, giant shared library; libxul.so. Yet they start via a binary executable... Again (just out of curiosity, like).....why the difference?

---------------------------------------------------------------------------------------

They say curiosity killed the cat. If that's applied to me, this 'cat' has had his 'nine lives' many times over..!


Mike.

[amigo]

The wrapper sets up the environment for the main program. Most things that will run-from-anywhere need this in order to find what they need. Sometimes this means that everything it needs which is not on the system will be found in the same place as the real-executable -all under one directory.

This was commonly done from back in the UNIX days. It also characterizes AppDirs, AppImages and Android/iOS APPs. There's even a special location for these things in the standard *nix file-system hierarchy. That place is /opt

Often you can actually start these main programs from the command line by passing all the environmental variables needed like this:
LD_LIBRARY_PATH=/path/to/app/libs program-bin

Making a wrapper executable means it can also be simply clicked to start. Many RoxApps are just an AppDir wrapping a wrapper script. Of course being a rox app you can fancy that up with right-click stuff or whatever.

[Mike Walsh]

Hi, amigo.

Mm.

The wrapper sets up the environment for the main program. Most things that will run-from-anywhere need this in order to find what they need.

Fair comment. So, I assume that when you say 'sets up the environment' that this includes the location of the main program itself.....whether binary or shared library. I'm guessing this is required so that the program knows where to look for stuff in relation to its OWN location, yes?

I find your assertion about AppImages acting the same to be.....unusual, I'll own. By their very nature, the entire thing's been combined into a single 'binary'; and, as I'm sure you're aware, they will run from literally anywhere. I don't quite see why these should require a 'wrapper-script' to run.....although, admittedly, I suppose that's exactly what I've done when making up Menu entries for them. By pointing the .desktop entry to a script in /root/my-applications/bin.....which is what actually starts them.


Mike.

[Keef]

If you look at how AppImages are constructed, you will find that they need a functioning AppDir anyway. You can unpack one with Uextract (or whatever takes your fancy), and have a butchers at the contents.

[amigo]

AppImage was designed exactly after the Rox AppDir. During construction they look like rox apps. You have a single top dir with content in one or more subdirs. You have an icon file an AppInfo.xml and a *binary* AppRun instead of a script. Then, the whole thing gets packaged into an iso image with a binary wrapper which makes it look like a simple executable. When you run it, the first bit of code creates a mount-point for the iso image, mounts it, chroots into it, then runs the AppRun code which is mostly setting up the environment, typically with at least LD_LIBRARY_PATH and PATH. For things like mozilla-products and others, the list of environmenatl vars passed is longer.

The end effect is that they execute exactly like rox runs AppDirs, but AppImages work on any system -even without rox. The down-side is that the whole thing is binary, so one may need to maintain several compilations, and there is no flexibility for hacking on them without learning that whole process used above to create AppImages.

The old UNIX stuff was main-frame users projects which could only be compiled in the HOME, right? And they passed source code around instead of bins, so you would unpack the source anywhere in your HOME, run 'make' and the run it with './program'. UNIX systems are/were like a platform -you can always depend on a specific set of underlying stuff being present. Anything your program needed which was not part of the platform would be expected to reside somewhere under *current directory* the relative directory: './' They also were mostly self-contained -I mean they wouldn't depend on third-party libs not part of the platform.

[don570]

Here's some advice on how to install gimp 2.8.22 in /opt.
I found it HERE
Appimages work the same way.

Code: Select all

Also, do not install GIMP 2.8 to /usr/local because on most systems, its libraries would override the libraries of a stable GIMP 2.6 installed into /usr, breaking your distribution-installed GIMP from slightly to completely. The same applies to any prefix your system uses for the purpose or overriding things in /usr/lib.

You install the new version into a separate prefix, say /opt/gimp-2.8 by passing --prefix=/opt/gimp-2.8 to the configure script. Then, in order to run the binary installed there, you change your environment to look for executables in /opt/gimp-2.8/bin by setting PATH=/opt/gimp-2.8/bin and you tell your linker to pick up libraries from /opt/gimp-2.8/lib by setting LD_LIBRARY_PATH=/opt/gimp-2.8/lib. Do not forget to export both variables.

You can use a tiny wrapper script called gimp-2.8 and place it into /usr/local/bin or elsewhere in your PATH. The script would look something like this:
	

#!/bin/sh

PATH=/opt/gimp-2.8/bin:$PATH
export PATH
LD_LIBRARY_PATH=/opt/gimp-2.8/lib
export LD_LIBRARY_PATH

/opt/gimp-2.8/bin/gimp-2.8 "$@"

[/quote]

[Mike Walsh]

Thanks for the replies, guys.

I took Keef's advice (cheers for that, BTW), and opened up a few of my AppImages (I've got a lot, believe me!), and had a look at them.

It's quite an eye-opener. I know I've made mention numerous times here on the Forum about Electron-based apps, and how they're becoming increasingly common these days. I run one (Temps), as detailed here:-

http://www.murga-linux.com/puppy/viewtopic.php?t=112131

.....which is available from Github as a native Electron-framed package. Imagine my surprise, upon opening these AppImages up, to find that every single one of them is constructed using the Electron framework.....so it seems my statement is increasingly true. That said, amigo's reference to the AppImage system packing these as a 'wrapped' ISO, which appears as a binary, actually makes sense now.

I do need to look more closely into this business of the 'LD_LIBRARY_PATH'; I guess it's probably more widely-used than I suspected. And it's how battleshooter helped me get round the NSS/GTK3 stuff in the recent Chrome releases.....by keeping all that stuff 'self-contained' within the browser package itself, so as not to interfere with other installed apps/programs which rely on the older versions to run.

There's summat new to learn every day! Thanks for the info, everyone; keep it coming...

Very much appreciated.


Mike.

[amigo]

LD_LIBRARY_PATH overrides -actually preceeds the normal path for libraries which ld-linux.so uses to start all dynamically-linked programs. Normally ld-linux.so looks first under paths specified in /etc/ld.so.conf. It then looks in the 'trusted' locations, that is, /lib and /usr/lib.

By using LD_LIBRARY_PATH you tell ld-linux.so to look first in the path specified. In the same way using PATH lets you override system-installed binary executables.

Using wrappers doesn't always work because if the program accesses normal config dirs (like /etc or /var) or other normal locations like /usr/share. That is why often a chroot is needed in order to provide a more complete substitute location/environment.

It may well be that AppImage is now using electron. The last time I looked I think this was not the case.