You are not logged in.
Pages: 1
Hello everyone, well recently i've been experimenting with trying to build static applications, and self-contained packages.
Ive messed around with Appimagekit and CDE to build self-contained apps and have finally come up with a method of my own for achieving massive portability with packages compiled with very new glibc versions.
what i've done is built gimp 2.7.2 on arch and managed to run it on ubuntu 11.04, 10.04 and 8.04, as well as centos 5.6 and the very old centos 4.8
basically I've rebuilt arch's glibc package to require kernel version 2.6.9 instead of 2.6.27 (still not sure if this is entirly neccessary)
install all the packages required to build and run the gimp.
make a directory called /Programs that has user read and write permission.
built the gimp to install all its required files into /Programs/Gimp/2.7
ran cde ( can be found here http://www.stanford.edu/~pgbovine/cde.html ) to find all the files that gimps requires, including other base tools, libraries etc.
moved all the libraries i need into /Programs/Gimp/2.7
and use this line to run
LD_PRELOAD=/Programs/Gimp/2.7/lib/libc.so.6 /Programs/Gimp/2.7/lib/ld-linux-x86-64.so.2 /Programs/Gimp/2.7/bin/gimp-2.7
which can be implemented into a script very easily.
So by simply makeing a /Programs directory and changing the ownership to user, this same binary can be ran on systems as old as centos 4.8 which is as old a system I would expect anyone to use, however it most likely works with any linux using 2.6 kernel.
Ill be uploading my packages to an fileserver of mine when I get the machine configured.
This may not help anyone here in particular, but its very nice if you have older machines and need the latest apps, or an unpopular distro where packages arent available, and building is quite tedious.
I would imagine these packages would work on *BSD with linux emulation but have not tested this yet.
Sorry for my bad writting. Hopefully some of you can help me make more packages, test or whatever, as it would be nice to have a one stop place for common GNU/Linux apps that arent distro/glibc/kernel dependent.
P.S. one good advantage of this aswell, is that the user has read and write access to the apps, which themselves do not require superuser rights to run, so why should they require rights to be installed. If anything this may be a security feature.
Offline
Hi kolbycrouch,
I've been experimenting with the very same ideas in the past, trying to build portable apps to be used from thumb drive. But I ended up with much less success than you I did pretty much the same steps as you (CDE + LD_LIBRARY_PATH/LD_PRELOAD), but didn't think of recompiling glibc. Did you do that manually or using modified pkgbuild? If you have the pkgbuild for that I would really like to see it, as I will definitely try this again
Anyway, thanks for sharing your experience!
Offline
That's very interesting. I'm wondering if that could be used to package closed-source games... (Not sure if that would package only a specific libgl for example and prevent it from running on another graphic card...)
Offline
Hi kolbycrouch,
I've been experimenting with the very same ideas in the past, trying to build portable apps to be used from thumb drive. But I ended up with much less success than you
I did pretty much the same steps as you (CDE + LD_LIBRARY_PATH/LD_PRELOAD), but didn't think of recompiling glibc. Did you do that manually or using modified pkgbuild? If you have the pkgbuild for that I would really like to see it, as I will definitely try this again
Anyway, thanks for sharing your experience!
I just used the pkgbuild from the abs.
Ill have my tarballs uploaded somewhere soon, as of right now, some very old systems do not have /lib/ld-linux-x86-64.so.2 which might be needed for plugin programs, I noticed this when running gimp 2.7 (that i built on arch) on centos, gimp would run if you used the prepackaged ld-linux-x86-64.so.2 however it wouldnt load the plugins unless I put that ld in /lib, not a problem really, but i wish i could assign some variable like $LD= or something. It doesnt seem to need the ld that it was built with, just anyone will do, since ubuntu hardy has /lib/ld-linux-x86-64.so.2 it worked fine without needing my prepackaged one.
Maybe someone can tell me why arch's default Glibc packages is built with --enable-kernel=2.6.27, as I have not noticed any difference after lowering it to 2.6.9.
P.S. Woot, am running gimp 2.7.2 flawlessly on my very old centos 4.8 (kernel 2.6.9, glic 2.3) workstation.
Offline
Maybe someone can tell me why arch's default Glibc packages is built with --enable-kernel=2.6.27, as I have not noticed any difference after lowering it to 2.6.9.
Just because it's the oldest with longterm upstream support...
From the news section:
News: Minimum required kernel version increased
2010-12-29 - Allan McRae
The update to glibc-2.12.2-1 increases the minimum required kernel version to 2.6.27. This kernel version was chosen as it is currently the oldest kernel with longterm support upstream. Users of the Arch "kernel26" and "kernel26-lts" packages are unaffected by this change.Those wanting to continue the use of an older kernel version will be required to rebuild the glibc package with the appropriate adjustment made to the "--enable-kernel" configuration option.
Source: http://www.archlinux.org/news/minimum-r … creased-1/
Offline
Pages: 1