How exactly do you update glibc?

[OscarTalks]

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.

Of course this is correct. In a new release of a distro the glibc will indeed be compiled from source.
The question of library directories (installation locations) can be determined as configure options when compiling
(Maybe --libdir=/lib64 for Slackware or --libdir=/lib/x86_64-linux-gnu which is a Debian or Ubuntu thing)
You would usually run ./configure --help in the source to see all configure options choose those in accordance with what the plan is.
Probably best to run make install with DESTDIR before considering any transplanting, because direct installation may break the build environment making life difficult.
Worth using search engine for "linux from scratch glibc" and look there for some pointers.
Must confess though I have not tried to do it in a Puppy, so just joining in with the chat in an interesting topic.

Important to understand though that glibc is a core library with some other stuff around it which is usually built first, and then all your other system libraries (even libstdc++ which is part of gcc) will depend on, and be linked to your original version of glibc, so if you actually remove your original you are hoping that your replacement will serve as a satisfactory foundation for everything, and if it is different from the original (which it must be) then there is always the danger that something somewhere will be unhappy and fail to work. That is why some might argue that "The best way to update your glibc is to update your Puppy (or other Linux distro) itself". Although you can do all the magic with more recent glibc packages and modified library paths and if that works then that may be a perfect solution.

[fredx181]

....
....
Although you can do all the magic with more recent glibc packages and modified library paths and if that works then that may be a perfect solution.

I agree, with modified library paths it would be ideal, if possible, but how is a mystery to me, and more and more I think there's no "global" solution, but hopefully I'm wrong.
Perhaps some more *real* Linux experts can shine a light on this ?

[wiak]

yes, problem is there are far more other libs involved than glibc so the ld-linux would need to specify --library-path ...:..... to whatever libraries it is to use whilst loading, but all crazy complicated and probably other issues at the end... Not worth the time IMO.

If glibc only then the following (not too old post) looks simple, but I haven't tried that

https://askubuntu.com/questions/1345342 ... 83#1345783

[bigpup]

OscarTalks is bringing up some of the ideas I was kind of wondering about, when I tried to compile from source.

I was trying it in F96-CE_4 with it's devx and kernel sources SFS's loaded.

This is what I was following to do it:
https://tutorials.tinkink.net/en/linux/ ... glibc.html

This sure makes it seem not that hard a thing to do.

I downloaded the glibc source from here:
https://ftp.gnu.org/gnu/glibc

I downloaded and decompressed (using uextract) the glibc-2.35.tar.gz

It made a directory glibc-2.35 with all the source files and needed stuff to compile in it.

From a terminal inside this directory, tried this command:

Code: Select all

mkdir build && cd build
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
make&&make install

The make&&make install is what produced a couple of errors and would not complete.

Compiling is really not something I understand much about, so the errors are not telling me anything I understand.

Maybe if one of you try this the errors will tell you something you understand

Maybe something specific in the command needs to be changed for Puppy Linux

Note:
When you do the configure process, all the files that are produced are placed in a build directory, that is in the glibc-2.35 directory.
If you want to try the command over again.
You must delete the build directory, so the command can make a new one and fill it full of files.

ldd --version in a terminal will tell you what version is in the Puppy file system.

[mikewalsh]

@bigpup :-

I think you'll find that wants to be

Code: Select all

make && make install

.....as opposed to

Code: Select all

make&&make install

See where the extra spaces are in the first example..?

Be that as it may, although I'm no expert with this stuff, I have never had any success trying to combine

Code: Select all

make

.....and

Code: Select all

make install

.....into a single command. I find it's better to run the two commands consecutively, one after the other, running the second when the first one finishes and is sitting there, waiting for input.

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

As for actually trying this stuff, yes; I concur. Always work with copies.

• A copy - or fresh install - of the target Puppy.

• A copy - always! - of the source code. This way, you can re-attempt it as often as you want. NEVER use the original.

• For second - and subsequent - attempts, I don't just delete the 'build directory'. I delete everything in the "work area" and start again from scratch with a fresh clean copy of the source code. Zero chance of contamination that way.

Mike.

[dimkr]

In the shell, a&&b is the same as a && b. Both do the same thing: run a, then run b if the former was successful.

In either case, b runs after a (not in parallel), so it doesn't matter if you run a, check for errors and then b, or just run a && b.

[wiak]

yes, problem is there are far more other libs involved than glibc so the ld-linux would need to specify --library-path ...:..... to whatever libraries it is to use whilst loading, but all crazy complicated and probably other issues at the end... Not worth the time IMO.

So with nothing better to do with my life... I tried big time.

I booted into older Zorin lite (Focalfossa based: glibc version 2.31
I compiled glibc version 2.35 and put it under /opt/glibc-2.35/bin
I had Linux Mint in other partition with chromium installed on that that needed glibc-2.35...
I patched that Linux Mint chromium:
patchelf --set-interpreter /opt/glibc-2.35/lib/ld-linux-x86-64.so.2 --force-rpath --set-rpath /opt/glibc-2.35/lib:/media/mcewanw/Mint/usr/lib/chromium chromium
Also tried:
patchelf --set-interpreter /opt/glibc-2.35/lib/ld-linux-x86-64.so.2 --force-rpath --set-rpath /opt/glibc-2.35/lib:/media/mcewanw/Mint/usr/lib/chromium:/usr/lib/x86_64-linux-gnu/ chromium
I checked all the libs that chromium needed using ldd command. They seemed all found, but clearly the versions under /usr/lib/x86_66 on my Zorin box were glibc 2.31 versions so when I tried running that chromium it said couldn't find blablabla lib.
I thus used LD_PRELOAD to load every one (but for last one) of the needed libs (81 of them...) from /usr/lib/x86_64. It was looking good; Mint chromium was satisfied with each thus pre-loaded!
And then the last one needed per:

./chromium: error while loading shared libraries: libgpg-error.so.0: cannot open shared object file: No such file or directory

SO.... excited... just needed to LD_PRELOAD /usr/lib/x86_84/libgpg-error.so.0; it was the lib still needed; nothing else giving errors now!!!

So used LD_PRELOAD for that and result!!! drums roll:

Code: Select all

/media/mcewanw/Mint/usr/lib/chromium/chrome_crashpad_handler: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /media/mcewanw/Mint/usr/lib/chromium/chrome_crashpad_handler)
/media/mcewanw/Mint/usr/lib/chromium/chrome_crashpad_handler: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /media/mcewanw/Mint/usr/lib/chromium/chrome_crashpad_handler)
[76818:76818:0815/131538.385196:ERROR:socket.cc(120)] recvmsg: Connection reset by peer (104)
Trace/breakpoint trap

So close... so far.... Maybe just a tiny step away from actual success. A step too far for me to sort out at this time of night! So Goodnight; enough is enough; a waste of time. Hmmm... maybe I can do something about that chrome_crashpad_handler?...forget it. Hmmm... let's try...

patchelf --set-interpreter /opt/glibc-2.35/lib/ld-linux-x86-64.so.2 --force-rpath --set-rpath /opt/glibc-2.35/lib:/media/mcewanw/Mint/usr/lib/chromium chrome_crashpad_handler

Well, would you believe it. Running that Mint chromium --no-sandbox now finally caused chromium window to pop up, but flickering like crazy madness (big blank window - nothing in it; says chromium in its title bar) - something really wrong with it, but it did run... kind of a success????? chrome_crashpad_handler seemed to want 2.33 or 2.34 (I gave it 2.35) - bizarre

[bigpup]

I hope some of you understand the above post.
A lot of it is geek spec to me

I am still trying the compile method.

I need to do an Internet search on the errors I am getting.

Just had a bad time, with computer getting locked up all the time, due to an install of clamav.
That thing somehow got a file on the drive, that gets activated, and tries to constantly run in the background, checking everything you do.
Slows the system down to basically a lockup condition.

Well, it was a version of clamav someone posted about and I tried using it.

I should have known better!

[fredx181]

I hope some of you understand the above post.
A lot of it is geek spec to me

See here: viewtopic.php?p=96198#p96198 about patchelf method , suggestion by @wiak, as a method to 'patch' the binary (that requires a newer glibc version) so that it works using newer glibc.
It may perhaps work with a single binary (simple application), but (IMO) will easily fail if a program has its own libs included as dependencies (that should be patched too ) (more complicated application).

[dragonpup]

I have successfully upgrade the glibc.
The procedure is as follow:
Assume the installed puppy is in frugal installation (I called it as Puppy-A)

The procedure:

1. Compile new version of glibc with –prefix=/
2. Do not install to the live system. Instead install to another folder say newver-glibc
make install –DESTDIR=newver-glibc
3. Manupilate the content of newver-glibc

a. cd newver-glibc/lib
mv ld-linux-x86-64.so.2 to ../usr/lib/ld-linux-x86-64.so.2
ln -sfn ../usr/lib/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2
b. cd newver-glibc/bin
ln -sfn ./lib/ld-linux-x86-64.so.2 ld.so
c. cd newver-glibc/lib
mkdir -p locale
cp ./usr/share/locale ./lib
d. cd newver-glibc
rm ./etc/ld.so.cache

4. reboot puppy to another frugal installation or boot the live cd
a. browse the pupsave folder of Puppy-A (The one you compile the newver-glibc)
b. copy all the contents of newver-glibc to the / of the installed puppy linux of frugal installation.

5 Reboot the Puppy-A in console mode, ie. boot param pfix=nox.
Ignore the error message during the reboot.

a. in the console, run command:
ldconfig

All Done.
6. Reboot the Puppy-A.
Use ldd to check your glibc version.

PS. Please take a full backup of your frugal installation just in case there is something wrong.

enjoy

[Wiz57]

I have successfully updated the GLIBC in some of my 32 bit Slackware based puppys, WHILE RUNNING!
Of course, I copied the respective savefiles to another place, just in case. Slacko 6.3.2 32 bit, an older
ScPup 32, and my customized S15Pup32 240413...what I did was download 5 packages from the Slackware
packages repo site for each version update, then used Puppy Package Manager to install the txz file...
I grab aaa-glib-solib, glibc-XXX-i686 (where XXX is the newer version, like 2.41), the glibc-i18n-XXX,
the glibc-profile-XXX and the glibc-zoneinfo TXZ file. No problems as of yet...

(Copy and paste from LxTerminal in my custom S15Pup)
# uname -a
Linux puppypc20561 4.14.173-lxpup-32-pae #1 SMP Fri Mar 13 07:42:34 GMT 2020 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
# ldd --version
ldd (GNU libc) 2.41
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
#

[fredx181]

I have successfully upgrade the glibc.
The procedure is as follow:
Assume the installed puppy is in frugal installation (I called it as Puppy-A)

The procedure:
...

Probably works at first glance this way, I'm curious if it's works ok in the long term, e.g. if you install many software afterwards, that it's still persistent, i.e. without any conflicting situations.
Anyone tested thoroughly ?

[dragonpup]

In long term run, probably the glibc has to be upgraded because the applications may need the new version of glibc.
For example, I run the bionicpup64, the browser palemoon new version requires the new glibc. That my reason to upgrade the glibc.
Now my bioinicpup64 is running with glibc version 2.40.

Linux puppypc6800 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux

root# ldd --version
ldd (GNU libc) 2.40
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

The palemoon version is 33.6.1.

Besides, application in appimage format can also be run without problem.

Compilation of new applications like pspp, binutils are okay without error.

Running of Python3 and Perl are also without any problem.

Try it and enjoy the upgrade of glibc for your existing puppy linux.

[ozsouth]

@dragonpup - You did this in bionicpup64? I do appreciate your effort in documenting steps, but I tried to follow your instructions using fossapup64 & glibc2.34. Had to first install python3 & found some missing items & some that didn't run. I figured some of them out (../configure --prefix=/usr --libdir=/lib/x86_64-linux-gnu --with-headers=/usr/include --with-binutils=/usr/bin) ; (make DESTDIR=newver install) , but when I tried manipulation, even with adjusted paths I had issues. Also, ld-linux-x86-64.so.2 in the original is a symlink to ld-2.31.so , so I also tried renaming all relevant new 2.34 lib entries according to to original protocol. I added new files into relevant folders in puppy.sfs & resquashed - was 10% bigger. I got a sort-of running desktop (zram didn't load), had to run fixmenus & restartwm to get main menus, sns & frisbee didn't work. Without a savefile/folder, settings would need redoing every bootup. I try to make generic changes that are distributable. Maybe other pups work better.

[Pikaxhu]

Hi

Zig allows to build with different glibc versions. Including musl.

Regards

Pika

[mikewalsh]

@ozsouth :-

A question.....if I may?

How did you get around the fact that, at the time glibc 2.31 was released, the "old" system was still in place.....but by the time of release for glibc 2.34, everybody and his dog had moved to the 'usrmerge' botch-up?

Extremely curious about this. I've tried using Bookwormpup64's glibc stuff and transplanting it into an older Puppy, but it just wasn't having it....

I have several assorted self-contained 32- & 64-bit glibc 'packages' (similar to the way we've employed watchdog's 'tweak' trick in the portable browsers), and every one of these transplants flawlessly. Post-usrmerge, however, it all goes to pot.

Mike.

[ozsouth]

@mikewalsh - the 'configure' string specs I used (3 posts up) SHOULD counter the usrmerge setup. That said, I still wasn't happy with the result.

[dragonpup]

@ozs outh:-

Yes, I did it in bionicpup64. The procedure, I think, is suitable for bionicpup64. For fossapup64, I found the the glibc contents are not stored neither in /usr/lib nor /lib. It
stores in /lib/x86_64-linux-gnu. According to your glibc compilation config, The final contents of the glibc are not thorough.

I compile the glibc within fossapup64 with the following config:

mkdir build
cd build
echo "rootsbindir=/usr/sbin" > configparms
../configure --prefix=/usr --disable-werror --enable-kernel=5.1 --enable-stack-protector=strong --disable-nscd --with-pkgversion=2.41 libc_cv_slibdir=/usr/lib

make
make install DESTDIR=glibc-2.40-focal

Afterwards, maniplate the contents of glibc-2.40-focal:

mkdir lib64
cd lib64
ln -sfn ../lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2
mv usr/lib lib/x86_64-linux-gnu
rm etc/ld.so.cache
cp lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/lib/

That is
The reboot fossapup64 using pfix=ram.
browse the pupsave folder with the glibc-2.40-focal, and copy all the contents of glibc-2.40-focal to the root of pupsave folder.
remember to delete the pupsave folder's /etc/ld.so.cache once again.

Reboot the fossapup64 in console mode (pfix=nox)
and run command ldconfig after rebooting.

reboot fossapup64 again, glibc-2.40 is installed