How to update to glibc 2.38?

[sonny]

640px-Linux_kernel_System_Call_Interface_and_glibc.svg.png (163.21 KiB) Viewed 2379 times

I just compiled the latest glibc-2.38.
Now, how do I update the old one?

https://easyupload.io/458063

[mikewalsh]

@sonny :-

Nice one!

Personally, I always do this manually.....but then, I've done it enough times that I know exactly what I'm looking for; what's got to be removed, what's got to be replaced.

I guess it would depend on where it was compiled as to how easy it would be to turn it into a package. Is this Fossapup64 (or older).......or a newer, 'usrmerge' Puppy?

Mike.

[rockedge]

Really interested in an unified way of updating the glibc. @mikewalsh is there a round about how-to that describes what you do manually to make the update happen?

[OscarTalks]

sonny,

I think you need to check all your configure options first of all to make sure everything is as we would want it. Some of those paths look wrong to me, there should be a lot of those files and directories under --prefix=/usr and not directly under "/". Also the executable and library binary files should be stripped. As for actually installing the package from source into a running system I believe it is problematic because glibc is such an essential deep-core package that if you try to do the usual "make install" (or new2dir make install) the installation process messes up the dependencies which are needed by the very tools you are trying to use to complete the installation. Everything just falls over, crashes and dies.

The suggested method seems to be to run make install with DESTDIR= so that you install everything as a directory tree in a temporary location with a view to copying it over into your system afterwards, deleting the old files as you do this. Even using this method, I still think it would be better to do this from another booted Puppy, with the one you are trying to upgrade actually shut down at the time. It is like major transplant surgery, so best done with your Puppy under general anaesthetic. Make sure you are in a position to reverse the process if the upgrade does not work out. Fortunately this is quite easy with the way Puppy is structured.

[sonny]

sonny,

I think you need to check all your configure options first of all to make sure everything is as we would want it. Some of those paths look wrong to me, there should be a lot of those files and directories under --prefix=/usr and not directly under "/". Also the executable and library binary files should be stripped. As for actually installing the package from source into a running system I believe it is problematic because glibc is such an essential deep-core package that if you try to do the usual "make install" (or new2dir make install) the installation process messes up the dependencies which are needed by the very tools you are trying to use to complete the installation. Everything just falls over, crashes and dies.

The suggested method seems to be to run make install with DESTDIR= so that you install everything as a directory tree in a temporary location with a view to copying it over into your system afterwards, deleting the old files as you do this. Even using this method, I still think it would be better to do this from another booted Puppy, with the one you are trying to upgrade actually shut down at the time. It is like major transplant surgery, so best done with your Puppy under general anaesthetic. Make sure you are in a position to reverse the process if the upgrade does not work out. Fortunately this is quite easy with the way Puppy is structured.

Cheers @mikewalsh and @OscarTalks.

I compiled it (safely) from Fossapup64 9.5 ISO running on Ventoy.

[mikewalsh]

@OscarTalks :-

The other thing that looks wrong to me, Oscar, is that there's no version number attached to the key glibc components that used to sit in /lib (and which I suppose now sit in /usr/lib, sym-linked back to /lib?)

I would expect to see - for instance - in /lib (or /usr/lib, sym-linked back):-

libBrokenLocale.so.1.....which ought to be a link pointing to libBrokenLocale-2.38.so. libcrypt.so.1 ought to be a link pointing to libcrypt-2.38.so. libc.so.6 should be pointing to libc-2.38.so.....etc,etc. I'm not seeing any of what I would expect to see (unless of course the guys who maintain the glibc have completely broken with the traditional naming scheme, in line with the 'usrmerge' change). Either that, or sonny's "recipe" wasn't as it should have been...

And then there's the "linker". ld-linux-x86_64.so.2 SHOULD be pointing to ld-2.38.so. Where is it? There's no sign of it anywhere.

Full marks to sonny for attempting this; can't fault him for having a go at it. But something wasn't right in the build-recipe, that's for sure.

============================

@rockedge :-

Um.....as for building the thing into a package; hoo, BOY.....

As mentioned, I always do this manually, while running from a completely separate Puppy. Like Oscar says, you cannot risk trying to do an install while running in the very same Puppy.....for the simple reason that you risk changing the very dependencies you need for the installer tools to function and complete their task.

I'm not entirely sure quite how battleshooter - one very clever lass! - constructed her glibc-2.20 upgrade for Saluki/Carolina. I believe the two sets of components, both new and old, can sit alongside each other until the last possible moment (at least in /lib; the component 'links' have to be 'swapped' at the last moment, plus the final step here is to swap the "linker's" sym-link over at the crucial moment). Swapping libstdc++.so.6 out is a bit more problematic, since the new component has the exact same name as the old. The same goes for the "gconv" & "audit" directories (traditionally in /usr/lib).

I always base my own upgrades on the layout watchdog established when he began to build his "glibc-tweaked" PaleMoon packages a few years back. From what I can see of it, watchdog used a 'barebones' subset of the full package which was JUST functional enough to get the job done. It's probably not correct.......but it always seems to work for me.

I use the 'layout' as a guide to what I need to 'borrow' from another Puppy which contains the glibc I want..... And of course, you need the "ldd" script from /usr/bin; this is what's called-on when you run

Code: Select all

ldd --version

.....to establish what version of the glibc is installed. Credits to jamesbond for pointing out to me that this is a self-contained script that is always part of the source code when built that way.

(I wouldn't recommend my own way of doing this to others, because the 'full' package seems to contain a lot of small components which my own method lacks.....plus I've noticed that some components seem to disappear/re-appear almost at random between different builds as time passes. Gets a bit confusing!)

Mike.

[sonny]

I did recompile it as the doctor @OscarTalks ordered.

https://easyupload.io/22syo7

Which files should I exclude before overwriting?

destdir.png (12.27 KiB) Viewed 2246 times

contents.png (14.91 KiB) Viewed 2246 times

usr-contents.png (14.79 KiB) Viewed 2246 times

[mikewalsh]

Hm. O-kayyy....

Examining the recompiled glibc 2.38, it looks as though the sym-link business has been done away with in /lib64. No "numbered" components at all; instead, each 'real' component is now labelled as its own soname. In fact, it's a trick I often employ myself when I need to add a 'lib' directory to any of the portables and it contains quite a few.....by removing the sym-links and re-naming, you halve the number of items within, it tidies things up no end.....and the application finds what it's looking for just that little bit quicker.

The dependency numbering system is there more for the user's convenience, so you can see at a glance what versions are installed; programs themselves are ALWAYS looking for the 'sonamed' link. In fact, looking through the entire package there are very few sym-links at all.....and what few there are, are all between /lib & /usr/lib due to the 'usrmerge' business.

However, I still say the safest way is to swap stuff over manually from a different Puppy. I would be a bit leery of trying to package this stuff; I do NOT wish to be responsible for bricking anybody else's system! I can't really advise, since I'm unsure of the safest way forward...

Sorry an' all that.

Mike.

[sonny]

Indeed...
The only way to replace a tire is when the vehicle ain't running.

[OscarTalks]

The way I would approach it is to compare the files in the original Puppy with the new files in the corresponding positions (hopefully) in the directory tree of the package. If that all looks OK the next step for me if I were testing would be to extract or copy out the main puppy .sfs as a directory tree and substitute the files from my compiled package in that (thus keeping my original puppy .sfs as "back up"). Then re-squash the directory tree as a new "manually re-mastered" main puppy .sfs and try substituting that in my frugal install and see if it boots and runs. I do this quite a lot when updating things in my personal re-masters, but have never tried to do it with all the components of glibc.

[sonny]

Exactly.
That's what I was trying to do to DARKPUPPY (a fossapup64 remaster).

[mikewalsh]

@OscarTalks :-

And that's the way I've always approached glibc upgrades myself; copy, then open up the main Puppy SFS, do whatever's necessary - there's no substitute here except to delete and replace, file by file, as is required - followed by re-packing and testing out.

In fact I go one further; I don't just copy the main SFS.......I duplicate the entire Puppy, from one sub-directory to another, then make up a new, temporary boot menu entry. If it all works fine after the modifications have been made, I simply delete the original, then re-name the copy back to the original & delete the temporary menu entry. Least disruption that way.

Mike.

[sonny]

@mikewalsh, @OscarTalks

"THE DEVIL IS IN THE PATH"

glibc-2.38.png (36.44 KiB) Viewed 2115 times

Tip (my case): Everything in /lib64 goes to /lib/x86_64-linux-gnu

@rockedge, I tried it on F96 to no avail (nothing but kp).

[Jasper]

@sonny

What is kp?

[rockedge]

@Jasper

kp = Kernel Panic

the dreaded system crash during boot due to the kernel bailing out because of some system instability.

@sonny Same thing is happening on my F96-CE_4 system.....kp

[traderx247215]

you only need these two slackware packages to update your old glibc

glibc-profile-2.38-x86_64-3.txz

aaa_glibc-solibs-2.38-x86_64-3.txz

just update the puppy package manager database if you are using a slackware puppy or search the internet for the files

[traderx247215]

here a link to the files

https://www.mediafire.com/folder/8prax7 ... lfk/shared