2016-04-19 17:45 GMT+02:00 Olof Bjarnason <olof.bjarnason@...400...>:
But now that you forced me to re-read the thread, I am also curious to why it's not possible to build&package on newer distributions, and be able to run on older...? As the dependencies are bundled into the ISO this should be possible?
Basically we have choice between two options:
Option 1: Include _all_ dependencies (besides the kernel) inside the AppImage. Advantage: Will run on target systems older than the build system. Disadvantage: AppImage will be rather large and contain many redundant libraries, doesn't feel "clean".
Option 2: Include only those dependencies in the AppImage that cannot be assumed to be part of all distros we are targeting. Advantage: The AppImage will be reasonably sized (roughly in line or even below the dmg for OS X and Windows msi). Disadvantage: the AppImage will usually NOT run on target systems older than the build system. Attempting to run the AppImage on older target systems will result in unresolved symbols (becuase the application and/or libraries inside the AppImage will try to access symbols on target system libraries which won't exist there if the target systems is older than the build system). Example: We decide not to include glibc in the AppImage because we assume glibc to be present on each target system. This means that the application and libraries which are contained inside the AppImage will try to resolve symbols using the target system glibc at runtime. If the target system glibc does not contain symbols that were present in glibc during build time, then the result will be "unresolved symbols", and the application will not run. This holds true for other libraries as well.
Note that this is not an either/or thing. We can decide for each library whether we want to bundle it inside the AppImage or rely on the library being part of the target system. However, libraries themselves have dependencies on other libraries, and this whole dependency tree needs to be taken into consideration. For most scenarios, a reasonable balance between AppImage size and compatibility can be achieved by compiling on old build systems, because then we can assume that the libaries on the target system will be "recent enough" (relative to the AppImage) and contain (at least) all the symbols that were there during build time.
In practice, the AppImage builds produced on CentOS 6 by Scribus, Subsurface, and MuseScore have been working for most real-life users. So far I did not get Inkscape bzr to build on CentOS 6 but possibly someone with more experience could get it to build there or on a similarly "mature" build system. In the meantime, I have used CentOS 7.