SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi all,
After libreoffice upgrade (installed using Alien precompiled package), I had to upgrade zlib package too on my slack 14.2, because new libreoffice version is linked against a zlib version newer than the one was installed on my system.
So, I now have a newer zlib version. But could be on my system many other packages compiled against the old one.
Could it cause any issues, like for instance any not working application or applications crashes?
If yes, is there a way to know which installed packages depend on zlib to rebuild/upgrade them against the new zlib installed, if needed?
I installed on my 14.2 libreoffice from here and it seems to use the system's zlib...
have you by any chance installed the package for current (that is at version 6.3.3 instead of 6.2.8)?
I'm not familiar with slackware, so I don't know if there is a way to show dependencies with the package manager, but you can use this in /bin, /lib, etc:
Code:
$ cd /usr/bin/
$ for f in $(find . -type f)
> do
> if ldd $f | grep -q libz.so
> then
> echo $f
> fi
> done
I wouldn't worry too much about a libz update breaking something. I could be wrong, but I doubt the ABI has changed much if at all. You could always rollback and put the newer version in a different directory. Then you can call libreoffice with a wrapper that defines LD_LIBRARY_PATH.
I'm not familiar with slackware, so I don't know if there is a way to show dependencies with the package manager, but you can use this in /bin, /lib, etc:
Code:
$ cd /usr/bin/
$ for f in $(find . -type f)
> do
> if ldd $f | grep -q libz.so
> then
> echo $f
> fi
> done
I wouldn't worry too much about a libz update breaking something. I could be wrong, but I doubt the ABI has changed much if at all. You could always rollback and put the newer version in a different directory. Then you can call libreoffice with a wrapper that defines LD_LIBRARY_PATH.
There is also a tool called sbbdep that can do this for you.
Libreoffice upgrade has been done to 6.2.8 version (the one Alien packaged for slack 14.2, not the 6.3.3 for -current).
Before the upgrade was likely installed zlib version 1.2.8, I don't remember but I find:
Code:
ls /lib64/libz.so.1.2.*
/lib64/libz.so.1.2.11* /lib64/libz.so.1.2.8*
Likely previous version was the 1.2.8 and libreoffice 6.2.8 needs the 1.2.11.
Anyway...
Almost the above packages were built against the old zlib version.
My system is not regularly updated for a long time, because it is used as desktop system and "if it works fine don't touch it".
I check for updates using slackpkg+ tool and there are many patches from official slackware repo... Also kernel glib and many other basic packages which many other installed depend on. So if I upgrade all packages slackpkg returned, I have to rebuild many other I got from SBo and some other built and packaged by hands.
More than a year ago, I did the above procedure: update official packages, update alienBob packages, and rebuilt all SBo packages (I asked here at LQ, you suggested hoorex tool if I well remember to generate a SBo queue, used with sbopkg after a little check to avoid "non SBo packages installed" were rebuilt).
That was a long procedure (my cpu is an old intel core 2 duo. Moreover it could be also a bit dangerous (some not working application, and "human time" requested to fix...). So this is why my system is out of sync with apps version found on remote repos.
An other reason is that I'd hoped Pat finally would have released the new slackware stable version (but after almost one year, nothing happened... not bad, my system work as usual form my tasks, but it isn't updated at now...).
If you want to avoid messing with your system libs, you could install the new libz locally and then use LD_PRELOAD when launching libreoffice. Example:
if you just applied the zlib update in /patches (1.2.8 -> 1.2.11) nothing should break.
let me say that would be a good practice to apply also all of the other updates in /patches, especially on a desktop machine where you use a browser, an email client, and other applications that interact with the network: nothing should break in doing that (but reading carefully the ChangeLog.txt is still strongly advised, never blindly do "slackpkg update ; slackpkg upgrade-all").
you shouldn't have to rebuild any SBo package after doing that: you have to only if you want also their newer versions.
My mistake...
Many of those "patches" packages are uninstalled because I had set up a multilib system thanks to AlienBob packages: slackpg+ shows patches packages as uninstalled and needed to update the system, but actually they are already installed and have the "compat32" tag as provided by AlienBob.
Also glibc and compilers (gcc & friends) appear as "to upgrade", but I had installed the same version reported, I just replaced it with the compat32 build... Alien rebuilds multilib packages after patched version are released by Pat as pure 64 bit.
Kernel, headers and related packages were actually outdated, I upgraded them and then I rebuilt nvidia closed drivers from SBo... But those are a very unique case.
I didn't involve the other SBo packages, and it seems all working fine at now.
My mistake...
Many of those "patches" packages are uninstalled because I had set up a multilib system thanks to AlienBob packages: slackpg+ shows patches packages as uninstalled and needed to update the system, but actually they are already installed and have the "compat32" tag as provided by AlienBob.
Also glibc and compilers (gcc & friends) appear as "to upgrade", but I had installed the same version reported, I just replaced it with the compat32 build... Alien rebuilds multilib packages after patched version are released by Pat as pure 64 bit.
*compat32* packages don't replace the packages in standard Slackware, nor the updates in patches: they contain 32 bit libraries and binaries to be installed alongside the 64bit ones.
gcc* and glibc* multilib packages actually replace the one in stock Slackware in a multilib system (but they are not named *compat32*).
so, in conclusion, you still need to apply all the updates in patches, also in a multilib system.
Yes you ar right, my mistake again... I was referring to "multilib" tagged packages:
Code:
# slackpkg search glibc
Looking for glibc in package list. Please wait... DONE
The list below shows all packages with name matching "glibc".
[ Status ] [ Repository ] [ Package ]
installed patches glibc-zoneinfo-2019c-noarch-1_slack14.2
uninstalled multilib glibc-debug-2.23_multilib-x86_64-4alien
uninstalled(masked) slackware64 glibc-2.23-x86_64-1
uninstalled(masked) slackware64 glibc-i18n-2.23-x86_64-1
uninstalled(masked) slackware64 glibc-profile-2.23-x86_64-1
uninstalled(masked) slackware64 glibc-solibs-2.23-x86_64-1
uninstalled(masked) slackware64 glibc-zoneinfo-2016e-noarch-1
upgrade patches glibc-2.23_multilib-x86_64-4alien --> glibc-2.23-x86_64-4_slack14.2
upgrade patches glibc-i18n-2.23_multilib-x86_64-4alien --> glibc-i18n-2.23-x86_64-4_slack14.2
upgrade patches glibc-profile-2.23_multilib-x86_64-4alien --> glibc-profile-2.23-x86_64-4_slack14.2
upgrade patches glibc-solibs-2.23_multilib-x86_64-4alien --> glibc-solibs-2.23-x86_64-4_slack14.2
As you can see slackpkg tool suggests to upgrade, for instance, glibc-2.23_multilib-x86_64-4alien to glibc-2.23-x86_64-4_slack14.2.
But if I want to preserve a multilib environment, I have to ignore that suggest and keep my "multilib" version already installed and already up to date to the last available release. In other words if I upgraded it, the "64bit only" package would replace the "multilib" one, and I don't want.
Maybe there is a way to tell slackpkg+ what repo have priority, so that it doesn't suggest upgrades that replace multilib counterparts already installed and up to date.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
