Glibc upgrade continues to report "old" version....? (SOLVED)

[mikewalsh]

Evening, all.

I'm just curious when I ask this.

Just for the hell of it, I've done a glibc 'upgrade' on Tahrpup 6.0.6 (32-bit) this afternoon. It's a bit of a rough'n'ready hack, if I'm truthful, though similar has worked for other Puppies before now. Glibc 2.19 has been replaced with Glibc 2.28, 'borrowed' from radky's 32-bit DPup Buster of a few years ago.

It's merely an experiment, working on a mirror copy of my existing Tahrpup install.....opening the base SFS, making the required changes, re-squashing the edited directory & substituting new for old. No, it hasn't been done the proper, 'official way', by either installing the appropriate packages from the PPM OR the 'correct' way by compiling/building from source......but I've done this enough times to know which files to swap over in order to obtain a functional Puppy afterwards. (This is the same glibc that's been used in the current 32-bit Pale Moon 'portable'.......which has had a watchdog-style glibc 'tweak' performed on it.)

I've noticed something again this evening; I'm posting from it now, in fact.....upgrade successful. Now; this doesn't always happen, but half the time when I perform a glibc swap, the change is apparently recognised & correctly reported. On other occasions, despite the swap being successful, the system apparently fails to recognise the upgrade, & continues to report the old glibc.....even though it's no longer "on the system".

Anybody know why this is? What am I 'missing', guys.....or do I just learn to 'live wih it'?

Mike.

[greengeek]

Sadly, no info to offer - but definitely watching...

[wiak]

You might be interested in the LD_PRELOAD of newer glibc in parallel with keeping older glibc for the binaries that depend on that older version: https://forum.puppylinux.com/viewtopic. ... 390#p93390

As I said, it doesn't seem to have been an approach adopted here before though maybe I just missed someone doing that. Simply replacing old glibc with newer one is not a good idea overall even if it seems to work 'most of the time' according to some threads advocating that.

[dimkr]

How did you swap glibc?

(Run /lib/libc.so.6 in the terminal if you're unsure what the glibc version is)

[bigpup]

Tahrpup 6.0.6 was never fully bug fixed.

It was released as a test version to see how some changes to Tahrpup 6.0.5 would work.
Really only released to have others test it.
666philb never fully finished it.

I would try this on a more stable finished version of Puppy.

[mikewalsh]

@dimkr :-

How did you swap glibc?

(Run /lib/libc.so.6 in the terminal if you're unsure what the glibc version is)

Um.....well; let me put it this way. It definitely wasn't achieved via the use of 'proper' packages, complied/built/packaged and supplied by the appointed maintainers of "official" repositories. Like I said, it was a real 'hack'..!

A few years ago, watchdog was experimenting with the use of a self-contained copy of a newer glibc in some of his Pale Moon builds, called via the LD_PRELOAD mechanism wiak mentions above. I used the same mechanism in a few of my portable browser builds, because it allowed folks running older Puppies to still run an up-to-date browser.

I basically took the 'encapsulated' glibc components from the 'tweaked' portable browser, and just swapped them with their counterparts in Tahrpup itself. Yes, I KNOW it's a 'hack', and probably not at all the correct way to do so, but.......99% of the time, it gives no trouble at all.

This is the browser build I'm talking about, if you're interested in looking at it:-

https://mega.nz/file/3DxxhLZY#xs0pq0PSA ... ZkjN7uutH8

I've used watchdog's 'tweak' technique - slightly modified to tidy things up for the portable build - along with one of Steve Pusser's recent 3rd-party semi-'official' builds of Pale Moon in 32-bit format. The glibc components came from josejp2424's 32-bit build of Busterpup, a couple of years ago.

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

I've occasionally considered doing what @wiak suggested above; putting a permanent newer glibc on the system, called via LD_PRELOAD for certain items. Since it IS self-contained, and is called this way, would it in fact matter where it was placed? I know it's not the best way to create a stable Puppy - - but I enjoy fooling around with stuff like this because Puppy IS so 'hackable' (and easy to repair/replace when you DO commit a FUBAR on it!)

Mike.

[dimkr]

Um.....well; let me put it this way. It definitely wasn't achieved via the use of 'proper' packages, complied/built/packaged and supplied by the appointed maintainers of "official" repositories. Like I said, it was a real 'hack'..!

What was the hack? Is it so embarrassing to share?

[mikewalsh]

@dimkr :-

Nah. Not embarrassing at all. The 'hack' was as stated above:-

I basically took the 'encapsulated' glibc components from the 'tweaked' portable browser, and just swapped them with their counterparts in Tahrpup itself. Yes, I KNOW it's a 'hack', and probably not at all the correct way to do so, but.......99% of the time, it gives no trouble at all.

This is the browser build I'm talking about, if you're interested in looking at it:-

https://mega.nz/file/3DxxhLZY#xs0pq0PSA ... ZkjN7uutH8

I've used watchdog's 'tweak' technique - slightly modified to tidy things up for the portable build - along with one of Steve Pusser's recent 3rd-party semi-'official' builds of Pale Moon in 32-bit format. The glibc components came from josejp2424's 32-bit build of Busterpup, a couple of years ago.

Well, to ME it's a "hack"..! But it's the sort of thing I get a great deal of fun out of....

Mike.

[Burunduk]

(Run /lib/libc.so.6 in the terminal if you're unsure what the glibc version is)

On Fossapup64-9.5, running /lib/x86_64-linux-gnu/libc.so.6 results in segmentation fault but LD_PRELOAD= /lib/x86_64-linux-gnu/libc.so.6 prints version information as expected. I could never understand what this libgtk3-nocsd.so.0 preloading hack is for.

[rockedge]

running /lib/x86_64-linux-gnu/libc.so.6 in F96-CE_4 produced a Permission Denied and checking the properties none of the execute groups were enabled.

Screenshot(56).jpg (6.14 KiB) Viewed 574 times

So after the permissions change:

Screenshot(54).jpg (19.13 KiB) Viewed 574 times

Screenshot(55).jpg (14.59 KiB) Viewed 574 times

[mikewalsh]

@rockedge :-

Um....right. How come - in your screenshot - libc.so.6 is an actual library? I'm in Tahrpup64 ATM, and here, libc.so.6 is a sym-link to libc-2.19.so. Even in MY copy of F96-CE_4, /lib/x86_64-linux-gnu/libc.so.6 is a sym-link, so......umm?

('Salright; I'm just curious, mate...... *shrug* )

Mike.

[jamesbond]

Um....right. How come - in your screenshot - libc.so.6 is an actual library? I'm in Tahrpup64 ATM, and here, libc.so.6 is a sym-link to libc-2.19.so. Even in MY copy of F96-CE_4, /lib/x86_64-linux-gnu/libc.so.6 is a sym-link, so......umm?

Glibc people made the changes starting with glibc 2.34.
Here's the exact commit that recorded the decision.

[mikewalsh]

@jamesbond :-

Ah. Thanks for that, Jim. I presume this is to do with the usrmerge stuff, then.....yes?

Mike.

[dimkr]

Many (most?) libraries include the version number in the file name, i.e. ls -l /usr/lib/x86_64-linux-gnu/*.1.

You still haven't explained how you swapped glibc (something more specific than "hack"), and how you checked what version you have.

[mikewalsh]

@dimkr :-

Many (most?) libraries include the version number in the file name, i.e. ls -l /usr/lib/x86_64-linux-gnu/*.1.

You still haven't explained how you swapped glibc (something more specific than "hack"), and how you checked what version you have.

Ah. I see. You apparently want me to write out a full list of every single item I swapped, yes? Right, right. Well, if that's the case, you'll be disappointed, because I simply haven't got the time to spare for that. However; I can & will do the next best thing, and supply screenshots of the containing folders from the 'tweaked' version of Pale Moon, where I sourced them.

As follows, these were the items that got swapped.....

These items got swapped in /lib:

[Click to enlarge]

Libstdc++.so.6 from /usr/lib:-

[Click to enlarge]

(I don't remember the exact version of libstdc++.so.6, I'm sorry to say. I did what I often do.....delete the sym-link, then rename the library as its soname. It still works, and tidies things up. Being 'precise' about versions doesn't interest me here; if it works, all well & good. Such an attitude probably horrifies you! )

The contents of /usr/lib/audit:-

[Click to enlarge]

I also swapped over /usr/lib/gconv. I presume you have more knowledge of this than I do; I don't have a clue what all these items do, and if I'm honest I'm not that bothered. Watchdog always swapped this directory in his tweaked browser builds; I simply copied his method.

This stuff is always done in one of my many 'WORK' areas whilst in another Puppy, since the base Puppy SFS needs unsquashing, the modifications made, then re-squashing again, and replacement of the original base SFS before finally re-booting again.

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

To check for glibc version, my usual method is to run

Code: Select all

ldd --version

...in the terminal while in the Puppy in question, though with some of these glibc 'swaps' it doesn't always report the new version. Running

Code: Select all

/lib/libc.so.6

....however, always returns the correct version.

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

I hope that's what you wanted. I'm guessing that for the OS itself, there's probably various text files missing when it's done like this. Like I said, the whole thing's an awful, messy 'hack' .....although 9 times out of 10, it does work without issues.

It's rather along the same lines as how I used to throw things together with LEGO as a nipper. That didn't always work out the way I expected it to, either!

Mike.

[dimkr]

Did you add the missing files, replace conflicting files and update the symlinks?

[rockedge]

Did you add the missing files, replace conflicting files and update the symlinks?

somewhat.

Screenshot(58).jpg (60.75 KiB) Viewed 602 times

[jamesbond]

geany /usr/bin/ldd and scroll down a little bit. You will see something like the screenshot below.

xscreenshot-20230709T211620.png (25.45 KiB) Viewed 570 times

ldd doesn't get the glibc version from anywhere. It's hardcoded inside the the file itself. So it can be out-of-sync with the actual installed glibc. All you need to do to correct it, is to also transplant /usr/bin/ldd from the new glibc.

Ah. Thanks for that, Jim. I presume this is to do with the usrmerge stuff, then.....yes?

I'm not sure, Mike. Could be that, or could be other things. But it does make it hard to check the glibc version which are not the default one, because it is not always possible to run libc.so.6. With the symlink, we can at least guess that from the name it links into.

[mikewalsh]

@jamesbond :-

ldd doesn't get the glibc version from anywhere. It's hardcoded inside the the file itself. So it can be out-of-sync with the actual installed glibc. All you need to do to correct it, is to also transplant /usr/bin/ldd from the new glibc.

A-ha! Right, right. See, I wasn't aware of that; the way watchdog originally put this stuff together for his 'tweaked' browser builds, he knew which version of the glibc he was using, and labelled the containing directory accordingly. And most Puppians wouldn't be bothered about the exact version in use, just as long as it all worked and the browser fired-up.

Of course, it never occurred to me that running

Code: Select all

ldd --version

.....must have been calling something "in the $PATH". D'oh!

Thanks for that tid-bit, Jim. Appreciated. I can now mark this as "Solved".

Mike.

[waxman]

Hi @mikewalsh and everyone else.

I had been tinkering with mike's palemoon portable.
I came across this post when I searched for the version numbers for the files used in the portable version.
To start wuth;
I booted up just the palemoon directory in safe mode in tahr 6.0.6. Only 3 files were needed by the terminal output.
Libstdc++, a glivc2.7 file and a gcc series file.
Mike you have asked in another post about updating libstdc++.
I extracted libstdc++ from various iso's and replaced the version in the portable with these.
So version 6.0.21 and older does not work. Version 6.0.22 and newer allows palemoon to load.
Then I copied a working version of libstdc++ into user/lib, linked it and deleted the libstdc++ in the portable.
The portable version booted up just fine.
I have a dotdeb installer for version 6.0.24 which automates the process.
Please find attached the installer. Just change the dotzip to dotdeb and run.

libstdc++6_7.2.0-8ubuntu3.2_i386.zip

(426.12 KiB) Downloaded 25 times

I then tried your trick of copying files from your portable into my /lib.
All I ended up doing was locking the laptop up on many occaisions and having to power down.
As I run in ram I can do quite brutal tinkering.

Thanks for your hard work Mike.

This may not be the place to post this but after much experimentation long story very very short I have now updated tahr 6.0.6 to Glibc2.30. Steve Pusser's files now allow palemoon to be installed directly. Working well so far in the experimental stage.

regards