How exactly do you update glibc?

[amethyst]

@fredx181 :-

Fred, I think you're onto summat there..! I sort of recognise some of the items in libc-bin, but the entire contents of the libc6 package are very familiar to me.

The libstdc++6 package may be required as well. This gives you libstdc++.so.6, the standard implementation of the C++ libraries. I think this is usually built as a matched item at the same time as the 'C' libraries. Perhaps not strictly necessary, but it never hurts to use the version from the same release as where you rip the libc6 stuff from. This is what watchdog always did with his glibc-tweaked browser builds.

(I have come across the odd app that is happy with the existing glibc version, but won't work until you upgrade libstdc++.so.6 by itself.)

I think you've given bigpup what he's been repeatedly requesting.....at long last.

Mike.

This also a good suggestion.

[jamesbond]

viewtopic.php?p=95983#p95983I've done this glibc switch many times before. Posted very early in this thread, should I also ask for credit now? LOL

Aah, I missed that Then of course, you should ask for credit, because that's the correct answer too And it's literally the second post as well!

[bigpup]

I thank everyone who has posted!!!!!!!!!!!!!!!

But I am looking for very detailed information on exactly how to do this.

I take the newer version from this Puppy and put it in this older Puppy is not details.

Some specific details have been posted and we can all use them.
Well I think I can

But I want to end up with a step by step how to do this, that anyone using Puppy Linux can follow and have good results.

--------------------------------------------------------------------------------------------------------------------------------------------------
Now it seems we have two sides on even doing this.

Some say not a good idea to even do this.

Some say I do this all the time.
-------------------------------------------------------------------------------------------------------------------------------------------------------------

I actually think there is possibly two ways to safely do this update of glibc.

Get it from another already built operating system version, that is compatible to the one you are using.

But what if there is no compatible newer operating system version to get it from, that has the glibc version you need?

Compile it from glibc source, in the version of the operating system you are using, may be only choice you have.
Compiling is exactly how it gets into a operating system being developed.

I do not think Ubuntu, Debian, Slacko, Mint, etc...... go find a version of Puppy Linux to get core Linux files and programs from.

Yes I am beating this to death and looking at all options!

[bigpup]

On numerous occasions , I simply used my package extraction tool to rip a newer glibc package from a newer Puppy and use it with an older Puppy by loading it as an additional drive (like an adrv). It normally works. It's better to manually delete the older glibc first.

OK I am a new user of Puppy Linux and even someone that has used it for some time.

I simply used my package extraction tool to rip a newer glibc package

What specific tool is this?
Where do I get it?
Is it in the Puppy version I am using?
How do I use this tool, never even seen it before?
What specific files do I extract?
Exactly where do I find them?

use it with an older Puppy by loading it as an additional drive (like an adrv).

What is an adrv?
How do I make this adrv?
How do I know it is made correctly?

It's better to manually delete the older glibc first.

How?
What exactly do you delete and from what location?
Is the delete only going to be in the Puppy save file/folder?
Or do I delete it from the specific Puppy version SFS file and repackage the SFS?

[amethyst]

Lots of questions. Well what version of glibc are you looking at, the newest? If so it may be worth a shot to try the downloads of fredx as provided above and simply install the files (easiest option first up, although I didn't check what is in there). If you want to remove the old glibc, you need to do so manually by editing the existing sfs and repacking it. With the older puppys like Fossa (don't know the newer ones) you can check contents of the glibc package in /var/packages and remove the files accordingly. An adrv is a normal sfs file that has been renamed as an adrv. Adrv's and other additional drives like the ydrv and bdrv are loaded "above" other sfs files in the layered file system and thus have priority over the contents of those files. Here is my package extractor tool if you want to check it out: viewtopic.php?p=77704#p77704

[fredx181]

The libstdc++6 package may be required as well. This gives you libstdc++.so.6, the standard implementation of the C++ libraries. I think this is usually built as a matched item at the same time as the 'C' libraries.

Okay, did replace libstdc++6 by dropping contents (and replacing) of package https://packages.debian.org/bookworm/am ... 6/download in my Debian Buster system.
And... my laptop still didn't explode !

Some say not a good idea to even do this.

Some say I do this all the time.

Doing a web search on the glibc upgrade subject, most answers to the question are 'don't do it'.
I'd say that you need expertise about it so.. 'don't do it if you don't really know what you're doing'
I do not have that expertise, just experimenting, so, btw, I don't deserve any credit !

About libc-bin: first thing I tried was replacing libc6, but then found that ldd --version still gave the old version and ldd is part of libc-bin, so "installed" that too.
edit: just see now that ldd is a shell script and has the display of the version coded;

case "$1" in
--vers | --versi | --versio | --version)
echo 'ldd (Debian GLIBC 2.36-9+deb12u1) 2.36'

[amethyst]

Okay, did replace libstdc++6 by dropping contents (and replacing) of package https://packages.debian.org/bookworm/am ... 6/download in my Debian Buster system.
And... my laptop still didn't explode !

It may not be such a good idea to actually replace the older libstdc as this may cause some issues with the applications in the older distribution. Just try to add the newer version as well.

[fredx181]

Okay, did replace libstdc++6 by dropping contents (and replacing) of package https://packages.debian.org/bookworm/am ... 6/download in my Debian Buster system.
And... my laptop still didn't explode !

It may not be such a good idea to actually replace the older libstdc as this may cause some issues with the applications in the older distribution. Just try to add the newer version as well.

Thanks, and how should that be done ? Add the newer version in some other place (perhaps /usr/local/lib ?)

[amethyst]

Okay, did replace libstdc++6 by dropping contents (and replacing) of package https://packages.debian.org/bookworm/am ... 6/download in my Debian Buster system.
And... my laptop still didn't explode !

It may not be such a good idea to actually replace the older libstdc as this may cause some issues with the applications in the older distribution. Just try to add the newer version as well.

Thanks, and how should that be done ? Add the newer version in some other place (/lib ?)

In the same location if you can, been such a long time back that I did these things. I'm sure I've done this before...

[mikewalsh]

It may not be such a good idea to actually replace the older libstdc as this may cause some issues with the applications in the older distribution. Just try to add the newer version as well.

Thanks, and how should that be done ? Add the newer version in some other place (/lib ?)

In the same location if you can, been such a long time back that I did these things. I'm sure I've done this before...

In theory, yes.....but in practice - since both newer AND older versions have the same, linked soname (libstdc++.so.6) - Linux won't let you do this. And if you DO put it in /lib, instead of /usr/lib, then your Puppy is going to get very, very confused.

Both versions will be active, both will be "in the $PATH".......and Puppy won't know which one it's supposed to use. This is why, if I update this item, I usually only go as far as the next newer build. This should not affect backwards-compatibility on a global basis. And if you should happen to have an app that insists on a newer build than that, then it's best to give it its own, dedicated version in a separate location, and called via LD_LIBRARY_PATH.

Mike.

[fredx181]

For info: I have it now like this:

2023-08-12_11-53-15.png (82.59 KiB) Viewed 1386 times

Where libstdc++.so.6 symlink points to the new version 0.30 and the older 0.25 is sill there.
See how it goes..., I plan to test this setup with new glibc for some time.

EDIT: Anyone know the best way to test ?
Something like "If you do this and that, probably big trouble expected..."

[amethyst]

Thanks, and how should that be done ? Add the newer version in some other place (/lib ?)

In the same location if you can, been such a long time back that I did these things. I'm sure I've done this before...

In theory, yes.....but in practice - since both newer AND older versions have the same, linked soname (libstdc++.so.6) - Linux won't let you do this. And if you DO put it in /lib, instead of /usr/lib, then your Puppy is going to get very, very confused.

Both versions will be active, both will be "in the $PATH".......and Puppy won't know which one it's supposed to use. This is why, if I update this item, I usually only go as far as the next newer build. This should not affect backwards-compatibility on a global basis. And if you should happen to have an app that insists on a newer build than that, then it's best to give it its own, dedicated version in a separate location, aand called via LD_LIBRARY_PATH.

Mike.

My libstdc versions have different version names (the actual files not the link). Copy the new file and it's libstdc-link to the older distribution. So the new shortcut will replace the link in the older version. Somehow this makes a difference if you have both actual files, if I remember correctly. All applications of my older distribution still works.

[fredx181]

Found first problem now on the setup with newer glibc: gimp won't start

gimp error

2023-08-12_13-18-23.png (98.81 KiB) Viewed 1364 times

EDIT: Noticed already earlier that when trying to install libc6 with apt, it gave message something like "cannot install, will break libgegl"
Tried to install newer libgegl version, but that gave me another error from gimp, refusing to run.

Now I do agree with don't do it , anyway, saw with my own eyes that things can seriously break.

[mikewalsh]

@fredx181 :-

Hm. The GIMP AppImage I use in the portable version seems to be happy to run literally anywhere, Fred. It's possible aferrero built these with statically-compiled binaries/libs, etc, but, er.....I really wouldn't like to say.

Mind you, the way this is constructed, it contains everything it needs to run. In that respect, it's what I think of as a "properly built" AppImage, i.e., it doesn't need to go off hunting around the system to find stuff.....

(*shrug...*)

Mike.

[fredx181]

@fredx181 :-

Hm. The GIMP AppImage I use in the portable version seems to be happy to run literally anywhere, Fred. It's possible aferrero built these with statically-compiled binaries/libs, etc, but, er.....I really wouldn't like to say.

Mind you, the way this is constructed, it contains everything it needs to run. In that respect, it's what I think of as a "properly built" AppImage, i.e., it doesn't need to go off hunting around the system to find stuff.....

(*shrug...*)

Mike.

Well it's not that I'm looking for workarounds (e.g. for gimp), just trying things to see if upgrading glibc breaks anything, really for testing only.
I guess the question from @bigpup has the goal to make upgrading glibc work without requiring any workaround ? Or.. ?

[ljlj]

regards
only,only in debiandog ( not in puppy) is possible
to change glibc!!!

[amethyst]

Found first problem now on the setup with newer glibc: gimp won't start
2023-08-12_13-18-23.png
EDIT: Noticed already earlier that when trying to install libc6 with apt, it gave message something like "cannot install, will break libgegl"
Tried to install newer libgegl version, but that gave me another error from gimp, refusing to run.

Now I do agree with don't do it , anyway, saw with my own eyes that things can seriously break.

Well, I see with both my workovers of Racy and Precise the libstdc versions were totally different like the one libstdc++.so.5 and the other newer libstdc++.so.6 and using the general link of the newest. I wanted a newer version of a browser to work without having to resort to one of mikewalsh's portables. It works beautifully for me. As far as glibc are concerned, I have removed the old glibc of all the older Puppys and are loading the newer glibc as an additional drive. None of them present problems, however, I have not tried other newer applications apart from browsers which is basically all I wanted to get working. With Bionic I also upgraded the glibc and are only using the newer libstdc.so.6 version for the newer browser.Works for the purpose I wanted it to work for.

[wiak]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside maybe possible (or store ld-linux and newglibc in different location easier) the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

patchelf changes the rpath inside the executable myapp such that it uses the glibc that you want. https://www.mankier.com/1/patchelf
https://github.com/NixOS/patchelf

I mentioned this use of two glibc on same system before in earlier post, but can't remember where. However just google for something like "how to use 2 different glibc" and you'll find plenty of pages explaining methods involving compiling, but also simply using patchelf to change rpath and so on. However, I'd generally simply upgrade distro... but... if you don't want to, get a hold of patchelf and try above.

[amethyst]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

patchelf changes the rpath inside the executable myapp such that it uses the glibc that you want.

I mentioned this use of two glibc on same system before in earlier post, but can't remember where. However just google for something like "how to use 2 different glibc" and you'll find plenty of pages explaining methods involving compiling, but also simply using patchelf to change rpath and so on. However, I'd generally simply upgrade distro... but... if you don't want to, get a hold of patchelf and try above.

Thanks, useful if it works.

[fredx181]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside maybe possible (or store ld-linux and newglibc in different location easier) the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

....

Thanks, but tried this method with spotify (on my normal setup, GLIBC version 2.28), no message about GLIBC being too old anymore, didn't work though, got "trace/breakpoint trap" when running spotify.
Perhaps more is needed to make this a success. I like the idea of having 2 different GLIBC installs though, would be nice if it works.

[amethyst]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside maybe possible (or store ld-linux and newglibc in different location easier) the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

....

Thanks, but tried this method with spotify (on my normal setup, GLIBC version 2.28), no message about GLIBC being too old anymore, didn't work though, got "trace/breakpoint trap" when running spotify.
Perhaps more is needed to make this a success. I like the idea of having 2 different GLIBC installs though, would be nice if it works.

Have you studied how they do it with the portable browser scripts? Actually you don't need the install of patchelf, to do it this alternative way. With your coding skills, looking at those scripts you may find a more "global" way of doing it instead of isolating every other application package on its own?

[williwaw]

I guess the question from @bigpup has the goal to make upgrading glibc work without requiring any workaround ? Or.. ?

I have been playing with the nix package manager, which tracks each app and dependency with a hash in its name, ie
q53f5birhik4dxg3q3r2g5f324n7r5mc-glibc-2.31-74/lib/libc.so.6:

It seems to download and use the specific version required rather than linking multiple versions

[fredx181]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside maybe possible (or store ld-linux and newglibc in different location easier) the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

....

Thanks, but tried this method with spotify (on my normal setup, GLIBC version 2.28), no message about GLIBC being too old anymore, didn't work though, got "trace/breakpoint trap" when running spotify.
Perhaps more is needed to make this a success. I like the idea of having 2 different GLIBC installs though, would be nice if it works.

Have you studied how they do it with the portable browser scripts? Actually you don't need the install of patchelf, to do it this alternative way. With your coding skills, looking at those scripts you may find a more "global" way of doing it instead of isolating every other application package on its own?

Easier said then done. Yes, I've seen the portable browser scripts (with e.g. setting LD_LIBRARY_PATH), but didn't see yet pointing to a different GLIBC ... don't think it will work.

[amethyst]

Easier said then done. Yes, I've seen the portable browser scripts (with e.g. setting LD_LIBRARY_PATH), but didn't see yet pointing to a different GLIBC ... don't think it will work.

It definitely works with a newer glibc set (which is included in some portable browser packages). Many older Puppys get browsers working like this when newer glibc are needed. You should ask mikewalsh to give you an example of such a launching script, unfortunately I don't have one myself.

[mikewalsh]

@amethyst :-

Well, thanks for the vote of confidence, Nic, but there I think we'll agree to differ. Fred is a far more accomplished scripter than I will EVER be; there is nothing I can teach him about this stuff....

On the subject of the 'tweaked' portable browsers, while it works with a self-contained glibc in that scenario, I doubt you'd be able to successfully segregate two or more different versions of the glibc within the main system itself. You'd get no end of trouble with the

Code: Select all

ld-linux.so.2

....."linker", I feel. I could be wrong, but at the very least it would then necessitate crafting custom launch scripts for everything that needs a different build in order to function. Exactly as we already have to do with the tweaked browsers, TBH.

I suppose you COULD write a 'generic' launcher for it, that uses variables in certain places to identify the specific app's executable before actually running it, but it does seem like a lot of unnecessary over-complication for what would only get used by a handful of stubborn 'hold-outs'!

This is one of those discussions that could just run, and run.....

Mike.

[amethyst]

@amethyst :-

Well, thanks for the vote of confidence, Nic, but there I think we'll agree to differ. Fred is a far more accomplished scripter than I will EVER be; there is nothing I can teach him about this stuff....

On the subject of the 'tweaked' portable browsers, while it works with a self-contained glibc in that scenario, I doubt you'd be able to successfully segregate two or more different versions of the glibc within the main system itself. You'd get no end of trouble with the

Code: Select all

ld-linux.so.2

....."linker", I feel. I could be wrong, but at the very least it would then necessitate crafting custom launch scripts for everything that needs a different build in order to function. Exactly as we already have to do with the tweaked browsers, TBH.

I suppose you COULD write a 'generic' launcher for it, that uses variables in certain places to identify the specific app's executable before actually running it, but it does seem like a lot of unnecessary over-complication for what would only get used by a handful of stubborn 'hold-outs'!

This is one of those discussions that could just run, and run.....

Mike.

Can you supply him with a script that references/links the newer glibc as well please? I'm sure I have seen something like that before with your portable browsers. Well, of course he knows more about coding than us that is why I want him to check that specific script (which I don't have). Could be beneficial to us all if there is a way, eh? Not sure why you seem to want to dismiss this off hand. Strange...

[bigpup]

A lot of very good back and forth information on this subject!

I truly thank everyone for their posts!

A lot of good ideas on what to do or do not do.

This is what Puppy is all about!
Everyone offering something to finally get to what will work!

Are we having fun yet?

I think I need to try some of what has been stated and see what happens for me.

Sorry, I have life getting in my way, just now, to spend the needed time.

Maybe we are all overlooking something needed to get it working 100%

Newer versions are in newer operating systems and work OK.

Maybe we need to find exactly what is needed for glibc

Thanks to all who have posted!!!

[bigpup]

I am wondering if the newer version of glibc files are being placed in the correct locations in the Puppy Linux file system

In internet searches I see it referring to the the location /lib64

But in Puppy OS it seems to be in /lib/x86_64-linux-gnu/

amethyst,
Where exactly are you putting the glibc stuff?

[mikewalsh]

Can you supply him with a script that references/links the newer glibc as well please? I'm sure I have seen something like that before with your portable browsers. Well, of course he knows more about coding than us that is why I want him to check that specific script (which I don't have). Could be beneficial to us all if there is a way, eh? Not sure why you seem to want to dismiss this off hand. Strange...

@amethyst :-

Mm..... Ah. I believe I know what you're thinking of.

You may be remembering back to the early days of the glibc-tweaked portables, when I was essentially following watchdog's recipe. A script outside the browser directory called a second script, inside the directory. Both the 'glibcxxxxx' directory AND the profile directory were at that time inside the browser directory.

This second script was the one that actually told the browser executable to make use of the items within the 'glibcxxxxx' directory, and THEN to launch.

See, what I did - quite some time ago - was to combine the two scripts together, and to move the 'glibcxxxxx' and 'profile' directories outside the browser directory. All in the interests of modularity, tidying things up, and making it far simpler for the in-built updater to do its thing, unencumbered by extraneous odds'n'ends that had no business being in there to start with.

I no longer HAVE that second script. Not in 'standalone' format, anyway......but if I did, it would have looked like this:-

Code: Select all

#!/bin/sh
#
export LC_ALL=C
#
HERE="$(dirname "$(readlink -f "$0")")"
#
$HERE/lib/glibc228/lib/ld-linux.so.2 --library-path $HERE/lib/glibc228/lib:$HERE/lib/glibc228/usr/lib:$HERE/lib/glibc228/libstdc++:/usr/X11R7/lib:$HERE $HERE/palemoon "$@" -profile "$HERE/profile"

This would have been for a 32-bit build of Pale Moon, using a 32-bit build of glibc 2.28, and dates back to the time before 'modularisation', when both the 'glibc228' directory AND the profile would have been INSIDE the palemoon directory...

-----------------------------------

These examples are from the present 'tweaked' 32-bit build of the PaleMoon browser, making use of Steve Pusser's 3rd-party custom compile, along with a copy of glibc 2.28.

The 'glibc228' directory is laid out as follows:-

'lib' contains:-

'libstdc++' contains (unsurprisingly):-

This is the actual library, but re-named to the 'soname'. Then 'usr' contains:-

.....which in turn contains:-

The additional two items are specifically required by the browser when running in older Puppies. As can be seen, we're essentially using the contents of the 'libc6' package here. We're NOT using the 'libc-bin' package, though should it be felt these WERE necessary, then following the same format, it would be simple enough to add them in & modify the script to 'call' them.

Hope that provides some further pointers!

Mike.

[wiak]

I believe the following is the way it is well-known about how to use two different glibc on same system (e.g. to run your browser that needs new glibc, but matching new 'interpreter' ld-linux must also be invoked. So assuming myapp is your browser, and the new glibc though stored alongside maybe possible (or store ld-linux and newglibc in different location easier) the old one has different major, minor version numbers:

Code: Select all

./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

....

Thanks, but tried this method with spotify (on my normal setup, GLIBC version 2.28), no message about GLIBC being too old anymore, didn't work though, got "trace/breakpoint trap" when running spotify.
Perhaps more is needed to make this a success. I like the idea of having 2 different GLIBC installs though, would be nice if it works.

Don't know if following helps your test situation - it concerned segmentation faults not trace/breakpoint trap, but issue might be similar (or not ):

https://stackoverflow.com/questions/847 ... ingle-host

Note for segmentation fault: you might be in the case where myapp uses several libs, and most of them are ok but some are not; then you patchelf it to a new dir, and you get segmentation fault. When you patchelf your binary, you change the path of several libs, even if some were originally in a different path. Take a look at my example below:

$ ldd myapp
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./myapp)
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./myapp)
linux-vdso.so.1 => (0x00007fffb167c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a9aad2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a9a8ce000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a9a6af000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9a9a3ab000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a99fe6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9a9adeb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9a99dcf000)
Note that most libs are in /lib/x86_64-linux-gnu/ but the problematic one (libstdc++.so.6) is on /usr/lib/x86_64-linux-gnu. After I patchelf'ed myapp to point to /path/to/mylibs, I got segmentation fault. For some reason, the libs are not totally compatible with the binary. Since myapp didn't complain about the original libs, I copied them from /lib/x86_64-linux-gnu/ to /path/to/mylibs2, and I also copied libstdc++.so.6 from /path/to/mylibs there. Then I patchelf'ed it to /path/to/mylibs2, and myapp works now. If your binary uses different libs, and you have different versions, it might happen that you can't fix your situation. But if it's possible, mixing libs might be the way. It's not ideal, but maybe it will work. Good luck!