You are not logged in.
I would like to understand better how libraries work, my question is:
For example, if i copy the icewm binary from /bin/icewm and put it under .local/bin/ it will never be updated by pacman, so it will work until...
ldd .local/bin/icewm [0]
linux-vdso.so.1 (0x00007ffdc7ae4000)
libgdk_pixbuf_xlib-2.0.so.0 => /usr/lib/libgdk_pixbuf_xlib-2.0.so.0 (0x00007f5714e83000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f5714e5e000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f5714e06000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f5714cdd000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00007f5714cc9000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f5714cbf000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f5714ca0000)
libfribidi.so.0 => /usr/lib/libfribidi.so.0 (0x00007f5714c81000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f5714c7c000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f5714c63000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f5714c56000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f5714c0b000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f5714b35000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f5714b28000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f5714b23000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f5714b1e000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f5714b15000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f5714b00000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f57149bd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57147e0000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f571469b000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f5714681000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f571465f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f5714498000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f5714491000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f57142d9000)
libffi.so.7 => /usr/lib/libffi.so.7 (0x00007f57142cd000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f571425b000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f5714252000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f5714220000)
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f571420d000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f57141d6000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f57141bc000)
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f57140ed000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f57140c3000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57140bb000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5715060000)
libmount.so.1 => /usr/lib/libmount.so.1 (0x00007f571405d000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f5714043000)
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f571401e000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f5714019000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f571400f000)
libblkid.so.1 => /usr/lib/libblkid.so.1 (0x00007f5713fbd000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f5713fb2000)
one of these libraries make some changes that break the outdated icewm binary.
Please correct me on this part as i'm not really sure.
I was thinking, what if i copy all the needed libraries and make icewm always use those? It would be similiar to the concept of an appimage?
Last edited by Skunky (2020-08-05 17:24:31)
Offline
You can prefix a binary with LD_LIBRARY_PATH to set a specific search path for (old) libraries. That is how I use Linux ELF binaries from the 1990s such as BMRT on Arch. Just create a shell script for it, e.g.:
#!/usr/bin/bash
SHADERS=/home/user/shaders LD_LIBRARY_PATH=/home/user/oldlibs /home/user/bin/rgl "$@"
Offline
While you could do that, you could also try and write a PKGBUILD for an older version that conflicts with (or provides, read the guidelines) the icewm package. You'd have to rebuild the package if the libraries change, but that should be automatable as well.
Offline
Why would you want to do this? What is your end goal? Do more recent versions of icewm introduce bugs? Or are there features lost that you want to maintain? Or features gained that you object to?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
First of all thanks everyone for taking the time to reply
@Morn That seems to be a very good solution for me, i tried to do something following your example like so (leaving old-libraries dir empty): LD_LIBRARY_PATH=/home/user/old-libraries/ /home/user/.local/bin/icewm and icewm worked, i think i'm missing something here
@Awebb That would be some extra work but still a viable solution thank you
@Trilby My end goal is to learn more about backward compatibility in general, icewm is just an example in this case, but an update could indeed introduce new bug as you mentioned (and happened with i3 few days ago) other than this, i can't see the need to update a window manager that just works, it already does everything i want and i doubt an "upgrade" can improve it for me, i hate things that gets fixed when they are not broken
Offline
... leaving old-libraries dir empty... I think i'm missing something here
Yes, you are missing something: the libraries. That "old-libraries" path should not be empty. It should contain the old libraries.
i can't see the need to update a window manager that just works, it already does everything i want and i doubt an "upgrade" can improve it for me
Then don't upgrade, just rebuild. Its much easier than all of the above discussion to simply keep the WM at the same version (and same source code) but rebuild as necessary to link to the new libraries. API-breaking changes are much less common than ABI-breaking changes (at least in libraries relevant for simple WMs). It's possible that at some point icewm would actually need to be patched to work with new libs, but a vast majority of the time a rebuild of the old code would work just fine.
In theory, you could also build a statically linked icewm binary which would be immune even from these changes (only actual protocol-breaking changes would matter, and I don't think X12 is coming anytime in the foreseable future, if ever ... and then even if it does in some decades in the future, it may well be backwards compatible with X11). In practice, however, statically linking X11 libs in arch may not be easy.
All that said, if icewm is just an example, and you are considering this for multiple packages - why are you using arch in the first place? If you want to prevent / avoid the defining features of arch, then simply use something else.
Last edited by Trilby (2020-08-05 15:12:27)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Yes, you are missing something: the libraries. That "old-libraries" path should not be empty. It should contain the old libraries.
But how can icewm still work, even with only none, one or few libs? I'm talking about the one that ldd gave me though.
Then don't upgrade, just rebuild. Its much easier than all of the above discussion to simply keep the WM at the same version (and same source code) but rebuild as necessary to link to the new libraries. API-breaking changes are much less common than ABI-breaking changes (at least in libraries relevant for simple WMs). It's possible that at some point icewm would actually need to be patched to work with new libs, but a vast majority of the time a rebuild of the old code would work just fine.
That implies that i would need to rebuild occasionally though? With the mentioned solution i would copy the libs and forget about it... or not?
In theory, you could also build a statically linked icewm binary which would be immune even from these changes (only actual protocol-breaking changes would matter, and I don't think X12 is coming anytime in the foreseable future, if ever ... and then even if it does in some decades in the future, it may well be backwards compatible with X11). In practice, however, statically linking X11 libs in arch may not be easy.
That's really interesting, thanks for mentioning statically linking
All that said, if icewm is just an example, and you are considering this for multiple packages - why are you using arch in the first place? If you want to prevent / avoid the defining features of arch, then simply use something else.
I'm considering this only for window managers and desktop environments because i would like a static workflow (not changing from one day to another) and that should be easy because they are not deeply inlaid with the OS, also using something else won't solve the problem because it's just how linux is made, old programs will break and i'm trying to understand more about this to see if this problem can be somehow mitigated.
I would hate to see my desktop and tray icons disappear after an update..cough..Gnome..cough
Offline
But how can icewm still work, even with only none, one or few libs?
It will as long as the needed libraries are still installed in the root filesystem. See `man ld.so` for the how the loader finds dynamic libraries. In short, LD_LIBRARY_PATH has high priority, so if a library is found in the specified path it will be used. If it is not found in LD_LIBRARY_PATH, then the linker checks the ld.so.cache, and if it's still not found there it falls back to looking in /usr/lib. If you are running the current icewm, then the libraries it needs are currently in /usr/lib. You will need *these versions* of these libraries copied to the "old-libraries" path for the icewm binary to continue functioning as these libraries get updated.
I'm considering this only for window managers and desktop environments... that should be easy because they are not deeply inlaid with the OS
This is mostly true of simple WMs (icewm likely included), but it is most definitely not for DE and DE tools. As soon as you try to implment this with gnome, and system tray tools, etc, you will find you are in a losing battle.
... using something else won't solve the problem because it's just how linux is made
What does this mean? This is not how linux is made. Most linux distros do have point releases with long support cycles and no need to even update after they are EOL (after they are EOL, they may not be officially supported, but there is no real expectation that they'd break). Also some of the BSDs make this far far easier as there is little expectation for the core OS and packages to be syncronized in any particular way. Arch is by far the worst for these goals as it is not only a rolling release, but a pure rolling release where versioned dependencies are often not even specified as it's just assumed that one must accept all available updates syncronously (e.g. partial upgrades are not only not supported but in fact are *expected* to often break things).
Last edited by Trilby (2020-08-05 16:50:42)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Besides, I'm sure icewm (and openbox, fluxbox, ...) has not changed much in the last decade or so. It should give you the desired "static workflow" for many years to come. If there really comes an update it's highly unlikely that it will break compatibility with itself or its users.
Offline
It will as long as the needed libraries are still installed in the root filesystem. See `man ld.so` for the how the loader finds dynamic libraries. In short, LD_LIBRARY_PATH has high priority, so if a library is found in the specified path it will be used. If it is not found in LD_LIBRARY_PATH, then the linker checks the ld.so.cache, and if it's still not found there it falls back to looking in /usr/lib. If you are running the current icewm, then the libraries it needs are currently in /usr/lib. You will need *these versions* of these libraries copied to the "old-libraries" path for the icewm binary to continue functioning as these libraries get updated.
Understood, thanks for taking the time to explain much appreciated
This is mostly true of simple WMs (icewm likely included), but it is most definitely not for DE and DE tools. As soon as you try to implment this with gnome, and system tray tools, etc, you will find you are in a losing battle.
Guess i will accept defeat and preserve my mental sanity then
...Also some of the BSDs make this far far easier as there is little expectation for the core OS and packages to be syncronized in any particular way...
Interesting, i will do some more research on this thanks
@ondoho That's also true, though i wanted to know if it was possible and it seems to be
Thanks everyone for the help at least i learned something new today
Offline