Puppy Linux Discussion Forum

bigpup wrote: ↑Sat Aug 12, 2023 5:44 am

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.

OscarTalks wrote:

....
....
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 ?

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

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:

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.

@bigpup :-

I think you'll find that wants to be

make && make install

.....as opposed to

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

make

.....and

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.

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 wrote: ↑Tue Aug 15, 2023 12:26 am

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:

/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

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!

bigpup wrote:

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).