asked on
linkers and library versions
hello
i am currently working on a project that involves cohabitation of binaries from multiple origins on the same ( linux ) system.
for the sake of this question, one can assume each binary is located in a working chroot
i use various hacks to get this to work without actually chrooting :
- modify the binary itself to change the linker and add adequate RPATHs ( easy but tedious )
- modify the kernel exec family of functions ( not really an option )
- replace binaries with shebangs of the form : env LD_LIBRARY_PATH=... /path/to/linker /path/to/actual/executable
- same as above but the replacement is performed on the fly by a custom fusefs
- i lack the C skills and knowledge to hack elf binary headers on the fly in fuse ( but that would be a nice trick )
stuff like appimage and the equivalents i know of do not fit the bill since i want multiple executables in a single "pack" available by calling their regular names and rather find a way to use existing stuff without repacking everything. appimage will be used where applicable, though.
QUESTIONS REGARDING THE POSSIBILITY TO MERGE CONTAINERS
when executables are linked to a linker or lib named whatever.so.1 but multiple versions of that file exist with the same name, should i expect them to be compatible ? does it actually work IRL ?
same question if i manage to include the latest version of each lib ?
i would assume libwhatever.so.3 to break even when the exact same version was compiled against different libc but i am wondering a naming convention might help overcome this issue ?
DISCUSSION AND SIDE QUESTIONS
most of the containers are read only and this can actually be enforced should that be needed. currently, i experiment with directories and tiny squashfs balls which i build using alpine packages but without sticking apk, shells, and other unneeded stuff in the containers. i am expecting other self contained images such as docker containers to work.
the kernel is currently linux but i am exepecting this mess to be portable to BSD using either BSD binaries or linux compat. if the BSD kernel has features i am not aware of that can help with this goal, switching to BSD is an option.
is there something obvious i am missing with any of the above solutions ? maybe issues with executables that might exec themselves ?
other ways to achieve the same goal i have not thought of ? preferrably without requiring dedicated packages.
any ideas and thoughts you might think is relevant to binaries execution and packaging is very welcome. i had rather not discuss issues relevant to init system, logging, location of config files and the likes : i am already aware of those.
--
side/different question : does anybody know of a "reverse syslog" fuse that would allow to mount /var/log in such a way whatever is written to log files is not actually written but sent to syslog using facilities and priorities based on the files names ? would you see some use for such a tool if i end up writing it ?
thanks for your time
i am currently working on a project that involves cohabitation of binaries from multiple origins on the same ( linux ) system.
for the sake of this question, one can assume each binary is located in a working chroot
i use various hacks to get this to work without actually chrooting :
- modify the binary itself to change the linker and add adequate RPATHs ( easy but tedious )
- modify the kernel exec family of functions ( not really an option )
- replace binaries with shebangs of the form : env LD_LIBRARY_PATH=... /path/to/linker /path/to/actual/executable
- same as above but the replacement is performed on the fly by a custom fusefs
- i lack the C skills and knowledge to hack elf binary headers on the fly in fuse ( but that would be a nice trick )
stuff like appimage and the equivalents i know of do not fit the bill since i want multiple executables in a single "pack" available by calling their regular names and rather find a way to use existing stuff without repacking everything. appimage will be used where applicable, though.
QUESTIONS REGARDING THE POSSIBILITY TO MERGE CONTAINERS
when executables are linked to a linker or lib named whatever.so.1 but multiple versions of that file exist with the same name, should i expect them to be compatible ? does it actually work IRL ?
same question if i manage to include the latest version of each lib ?
i would assume libwhatever.so.3 to break even when the exact same version was compiled against different libc but i am wondering a naming convention might help overcome this issue ?
DISCUSSION AND SIDE QUESTIONS
most of the containers are read only and this can actually be enforced should that be needed. currently, i experiment with directories and tiny squashfs balls which i build using alpine packages but without sticking apk, shells, and other unneeded stuff in the containers. i am expecting other self contained images such as docker containers to work.
the kernel is currently linux but i am exepecting this mess to be portable to BSD using either BSD binaries or linux compat. if the BSD kernel has features i am not aware of that can help with this goal, switching to BSD is an option.
is there something obvious i am missing with any of the above solutions ? maybe issues with executables that might exec themselves ?
other ways to achieve the same goal i have not thought of ? preferrably without requiring dedicated packages.
any ideas and thoughts you might think is relevant to binaries execution and packaging is very welcome. i had rather not discuss issues relevant to init system, logging, location of config files and the likes : i am already aware of those.
--
side/different question : does anybody know of a "reverse syslog" fuse that would allow to mount /var/log in such a way whatever is written to log files is not actually written but sent to syslog using facilities and priorities based on the files names ? would you see some use for such a tool if i end up writing it ?
thanks for your time
Linux* executable* elf
Last Comment
skullnobrains
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Mention why you're going through all this effort.
Describe the specific problem you're trying to resolve.
For example, you mention apk + squashfs, so a few considerations... as it seems you're trying to conserve disk space...
1) You can easily run Alpine LXD containers, which gives you a BusyBox/libmusl based system.
2) Be aware this won't really save you any space, if you install a single large system, like install LAMP + your container size will relate to LAMP Stack code size, so your Alpine container size will approach Ubuntu container size anytime this occurs.
3) You'll also have your log files, which can be large.
Once log files build up for a week to 10 days (required to debug problems), then your Alpine + Ubuntu container size will become similar.
Describe the specific problem you're trying to resolve.
For example, you mention apk + squashfs, so a few considerations... as it seems you're trying to conserve disk space...
1) You can easily run Alpine LXD containers, which gives you a BusyBox/libmusl based system.
2) Be aware this won't really save you any space, if you install a single large system, like install LAMP + your container size will relate to LAMP Stack code size, so your Alpine container size will approach Ubuntu container size anytime this occurs.
3) You'll also have your log files, which can be large.
Once log files build up for a week to 10 days (required to debug problems), then your Alpine + Ubuntu container size will become similar.
ASKER
thanks for chipping in.
i am experimenting with different ways to package software that do not rely on chrooting or any other container techniques. i am more than fluent with all sorts of containers and also have experience with lightweight containers that do NOT contain a whole system or a package manager. LXD, LXC, docker are besides the point.
basically, i am looking for something different, easy to distribute, read only and that can work without relying on chroots. i figure most limitations i experience come from the lack of hooks in exec() and the fact linker paths are hard coded in elf executables.
disk space is not much of an issue in this context. i had rather not use up memory uselesly, though but the forseable overhead is not that much of an issue.
--
if i get you well, libx.so.2.3 is not backwards compatible with libx.so.2.2 though both will be installed as libx.so.2 (sigh). pretty much what i though unfortunately.
--
i might post a different question regarding the syslog part but not right now. my goals are rather obvious : i want a virtual /var/log directory that non syslog-enabled apps can log to and want the writes to end up in syslog. i am well aware that simple config, spawing apps in a pipe and the likes can allow to do the same but would love a generic zero conf solution better.
i am experimenting with different ways to package software that do not rely on chrooting or any other container techniques. i am more than fluent with all sorts of containers and also have experience with lightweight containers that do NOT contain a whole system or a package manager. LXD, LXC, docker are besides the point.
basically, i am looking for something different, easy to distribute, read only and that can work without relying on chroots. i figure most limitations i experience come from the lack of hooks in exec() and the fact linker paths are hard coded in elf executables.
disk space is not much of an issue in this context. i had rather not use up memory uselesly, though but the forseable overhead is not that much of an issue.
--
if i get you well, libx.so.2.3 is not backwards compatible with libx.so.2.2 though both will be installed as libx.so.2 (sigh). pretty much what i though unfortunately.
--
i might post a different question regarding the syslog part but not right now. my goals are rather obvious : i want a virtual /var/log directory that non syslog-enabled apps can log to and want the writes to end up in syslog. i am well aware that simple config, spawing apps in a pipe and the likes can allow to do the same but would love a generic zero conf solution better.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
if anyone is interested i ended up writing the syslog fuse in perl though it has been reimplemented in another language (one of c, c++ or go) by my client. my implementation is in perl since i had to write said code overnight. the initial implementation used quite a few lousy hard coded stuff but i ameliorated it since them and it is indeed usable. message me if you are interested.
What you've described is solved by container systems.
You'll use Docker with ephemeral data (date dies across container restarts).
You'll use LXD with persistent data (data lives/persists across container restarts), for example any time you have complex config setups or SQL data.
Since all projects I manage have complex configs or SQL databases I use LXD, which means.
1) Each container runs it's own Linux Distro... so package management (library/executable matching) is simply handled.
I've never thought about this, because I only run Ubuntu at machine level + inside containers, so package management... simply works...
With RedHat/CentOS/Fedora + friends, you'll have much more excitement... adventure... as package management always requires... hours of attention from time to time to manually resolve dependency problems.
So if you like futzing with packaging problems, use RedHat. If not, use Ubuntu.
2) To manage library updates.
Create a new container with whatever Distro you like.
Backup files + databases in old container.
Restore into new container.
Rebuild your whatever.so.* version library against container version of all libraries + include files.