Modularization of glibc -- a new project

[mikeslr]

amethyst mentioned upgrading glibc here, https://www.forum.puppylinux.com/viewto ... 238#p70238 --and see the post which followed that one-- and has already used to technique in creating Precise Exta, https://www.forum.puppylinux.com/viewto ... 697#p67697 and Racy Extra, https://www.forum.puppylinux.com/viewto ... 497#p68497.

The procedure circumvents the problem caused by having glibc 'built-in': Web-browsers employ openssl to 'hand-shake' with websites. openssl is dependent on glibc. But many other applications are also dependent on glibc and an operating system, itself, can only employ one. [Until now the 'work-arounds' have been to either include a different glibc in the web-browser itself (which can be done with mozilla & clones, but not Chromium & clones) or to run a web-browser in a chroot, essentially another operating system. Or to change to a newer Puppy ]

Amethyst's technique involves these steps which have to be manually undertaken:

(1) Obtain all the libraries needed for a newer glibc.
(2) Package it in an sfs [the kind I refer to as 'alphabet' as they consist of a letter followed by "drv_NAME-OF-PUPPY_VERSION-NUMBER.sfs"; for ease of remembrance the letter I'd use is 'g'. So, for example, if used by fossapup64, its name would be gdrv_fossapup64_9.5.sfs].
(3) Modify initrd(?z) so that on boot-up that 'gdrv.sfs' would be copied into RAM.
(4) Remove/delete 'all of' the builtin 'glibc': amethyst's post explains how.
(5) locate the gdrv.sfs adjacent to the other Puppy-System files.

Much of the above can be automated at the woof level. Just as with 'hugh-kernels' --vmlinuz and zdrv.sfs-- and fdrv.sfs (firmware), fans could publish gdrv.sfses.

The modification to initrd isn't difficult. IIRC, gyrog, jakeSFR and taersh and shinobar began investigating and working on that mod a couple of years ago; and IIRC amethyst posted a recipe on one of the treads for the above modified Puppys. Quickpup and some other new Puppys already employ that (or a similar) modification.

If modification of initrd was done at the 'woof' level; users wouldn't have to. And with gdrv packages being available --we would not need many-- swapping glibc's would be as easy as swapping 'kernels'.

[keniv]

@mikeslr
I do not wish to be negative about this but if "modularisation of glibc" is to be of use it actually has to work for ordinary users as well as the experts within the puppy community. I consider myself as a user. I have tried both Racy Extra and Precise Extra and can get neither to work properly (please see my posts in both the Racy Extra and Precise Extra threads). If I could get either to work I consider that they would be useful to me and could be to others as well. Could I ask if you have tried either of these. If so can you let me know if you were successful and if you were how you got them to work. I appreciate that this may be a new idea which might be in development and perhaps we should expect problems but the inability to get either of these to work is extremely frustrating. If it's only for experts then perhaps I should give up.

Regards,

Ken.

[dogcat]

Referencing https://www.linuxquestions.org/question ... te-788256/ as my source for information.

A couple things from that discussion if I understand it correctly.
Replacing / changing the version of glibc can be done but issues can arise. When updating the system kernel version that glibc is compiled against the kernel headers from the kernel version glibc was originally compiled against should be retained (as well as the current kernel's headers, of course). Also mentioned is there is also the chance that the c compiler will not work with the replacement kernel.

The information also mentions that minor kernel version changes should not require glibc to be rebuilt against the replacement kernel but when changing glibc between major kernel updates the glibc should be compiled against the updated kernel.

There is a lot more information about glibc at that link, the discussion is 4 pages long.

[amethyst]

Referencing https://www.linuxquestions.org/question ... te-788256/ as my source for information.

A couple things from that discussion if I understand it correctly.
Replacing / changing the version of glibc can be done but issues can arise. When updating the system kernel version that glibc is compiled against the kernel headers from the kernel version glibc was originally compiled against should be retained (as well as the current kernel's headers, of course). Also mentioned is there is also the chance that the c compiler will not work with the replacement kernel.

The information also mentions that minor kernel version changes should not require glibc to be rebuilt against the replacement kernel but when changing glibc between major kernel updates the glibc should be compiled against the updated kernel.

There is a lot more information about glibc at that link, the discussion is 4 pages long.

May be so but I'm using the same glibc on 6 different Puppys old and new without any issues (apart from one very old Puppy which has some issues with any glibc older than version 2.20, but that's a system limitation of that Puppy it seems). I don't even know how this glibc was compiled but it is much newer than the glibc that came with the Puppys I run. Seems to work without issues for me. Also, changed the kernels of these Puppys and still no issue with different kernels and the glibc. I've also used different glibc versions with these Puppys and still no issues, everything seems to work. So maybe an overly cautious report...or maybe Puppy just handles this better than other distributions. It's very handy to be able to use newer glibc (and a newer kernel) with an older Puppy. I do find that as far as kernels go, your particular machine/hardware may play quite a big role (the Puppy version not so much it seems). Some kernels boot very slowly on my old laptop although almost all of them work without issues once desktop is loaded. In my experience, swapping glibc and kernels work well in general.

[mikeslr]

Referring to racy-extra and precise-extra keniv wrote "Could I ask if you have tried either of these?"

Simple answer. No. Fleshing that out. I have 2 computers almost always up and running: my desktop in my "basement-office" where I do most of my explorations, but which balks at running 32-bit systems such as the two above; and my laptop in the den, where I 'veg-out' watching TV, and use mostly for surfing the web when something on TV generates a question like "Where do I know that actor from?" or "What's the reality behind that 'must have' thing being advertised?"

amethyst's original posts caught my attention but more for the system change than the use he made of it. And that circumstance continues. But when I read his post here, https://www.forum.puppylinux.com/viewto ... 238#p70238 the idea of swapping glibc's having percolated in the back of my mind for a while was transformed from 'something I find interesting' to 'something which might be of value in Puppy's evolution'.

Your query inspired another idea: Use the technique to 'up-date' Tahrpup64's glibc. I've added it to my 'ToDo' list. But to be honest: (a) my gut feeling --as dogcat's post suggests-- was that there may be technical issues which should be considered and my background isn't technical*, i.e. this should be undertaken by someone who knows what (s)he's doing. Hence my post subtly calling for volunteers. (b) The ToDo list just keeps growing and mostly serves as an excuse for putting off doing those things on my "MustDo" list.

-=-=-=-=-=-
* I grew up in a business community where the questions --what do people need? want?-- was always in the background. It's 2nd nature to me to walk through a small town or neighborhood of a city and think this absent business could be profitable here.

[mikewalsh]

@dogcat :-

I wouldn't take anything you read about over at LQ.org too much to heart.

This is mostly a bunch of veteran Linux users from the early days, to whom anything & everything to do with Linux is of the utmost importance. A lot depends on how serious you wanna be...these guys are the sort who take their "hobby" extremely seriously!

These are the sort of guys who were used to compiling absolutely everything they had to use. Trouble is, most of 'em are still stuck in that mind-set, and refuse to even accept that there's alternative ways round most things nowadays.

The other thing being that you're in the Slackware sub-forum there. As far as Slackware users are concerned, LQ.org IS the Slackware Forum (they don't have their own). And LQ.org is very proud to be considered the 'home of Slackware'.

Slackware is the oldest Linux distro still extant. Patrick Volkerding, way back in 1993, took the view that HIS distro would only just get users functional. Anything over and above the basic, the user had to compile.....and, to this day, the Slackware "preferred" way is still to compile everything on-the-fly, as you go. Hence the popularity of 'Slackbuilds'.....which are, I believe, basically the source code + a 'compiler recipe'. (I could be wrong about the components of a Slackbuild). Many of their apps only come this way; the user has no option but to build 'em if they want 'em.

Slackware does NOT mollycoddle its users. This is why it appeals so much to long-term Linux geeks, because its' premise is the only one they've ever known.

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

Yes, I daresay they're perfectly correct about the business with the headers, though the kind of scenario many of us would use a 'modular glibc' for is simply to run newer applications.....and as I'm sure you know, even that isn't guaranteed to work. I rather doubt any Puppians would then try to use a different glibc to actually compile against, because it would never match with all the stuff in the DevX. I certainly wouldn't, and would want to have things so I could swap back to the 'original' glibc should I need to compile anything.

Having proved the value of the concept with the glibc 'tweak' from watchdog, which I've used in a number of portable browsers over this last few years, I DO think it merits further exploration.

Mike.

[mikeslr]

This posts fleshes out the reason I think further exploration is of value. But if you just want to follow the mechanics, skip down to the last line where you’ll find a link.

Thanks for chiming in, Mike. While 'vegging' per above I decided to read the discussion dogcat referred to. As I don't compile --that would require internalizing a language, something I know I'm not good at-- it's a blind spot. Not only don’t I do it, I don’t think about it. Some one has to remind me that compiling not only exists but is vital in both the creation of an operating system and the evolution of operating systems.

I’d make a lousy True Believer. By now when I read or listen to anything touted as ‘The Truth’, I do so as a skeptic simultaneously testing the information given against a life-time of varied experience and exposure to the opinions of those touting a different Truth. What are the limitations and exceptions to ‘This Truth’?

My ‘take-away’ from the discussion dogcat suggested is that just updating glibc would likely result in a substantial inability to compile new applications under the resulting operating system. Well, I don’t compile; and I suspect neither do 99% of Linux Users.

We became the dominant species on this planet NOT because all of us can do one thing well –like cheetas at running-- but because as a species we are ‘generalists’, comprised of individual who are specialists, with the ability through language to co-ordinate our individual efforts. And that’s analogous to where I think Puppy Linux belongs in the spectrum of Linux operating systems. OOTB it is not the best system for security, video production or anything else. OOTB it is a generalist operating system. But though the information made possible by the Forum anyone desiring to do so can make use of the efforts of specialists to obtain the computing system best able to accomplish his or her goals despite the hindrance of a computing environment which would not be up to that task if the use of a different, currently touted Linux was attempted.

Linux operating systems are free. That condition eliminates the need of each to be profitable in order to continue to exist. In a system dominated by monetary interests, profitability is the test for determining the value of something to consumers: the reason for continuing to produce it. But users of free Linux are also consumers.

Solataire has been around for at least 300 years. Many of us have played it as a pleasant way to while-away hours without having to think. Ernõ Rubik invented the Cube in 1974. Many of us have played with it as a pleasant way to think without having to later act with consequences. But an operating system is chosen to accomplish ‘real world’ tasks, even if only to demonstrate one’s existence, communicate with others or play a variety of games. Android now dominates that market. What remains for the rest of Linux operating systems is their use in productive activities.

Why choose Puppy Linux from among a thousand other systems? Who is its ‘market’? How do we increase our ‘market share’ except by being more useful than other Linux operating systems?

The best word-processor, ever, was and still is WordPerfect. It was also once the most popular. It lost market-share to Microsoft's Word because Microsoft knew how to leverage the advantage it had. Loosing market-share is worse for Puppy: those who might have become Puppy's next generation of creators and frequent Forum advisors will find some other operating system to invest their time and energy in, and having done so --like compiling for me-- Puppy will not even be something they think about.

Examination of Forum members –market analysis-- reveals that users of Puppys are rarely those with sparklingly-brand-new, top of the line, computers. They are almost always people trying to get a few more years of useful life out of an old computer. That circumstance should provide Puppy with an advantage: OOTB Puppy is NOT an operating system constantly changing to get the most out of the newest hardware. Someday every computer user will only possess a computer which is no longer sparklingly-brand-new, top of the line.

Add another factor: I still primarily use Bionicpup64. MikeWalsh and BarryK have expressed their continued fondness for Racy. And amethyst has devoted his energies to ‘updating’ Racy and Precise. None of those Puppys are Puppys I now recommend to anyone unless their computer’s limitation compells it. But all reflect a universal human condition: we over-value what we already possess.

[We love our old dog. But the ASPCA has a difficult time finding adopters for the old dogs they shelter. We may give what we can to ‘Save the Children’. But how much would we sacrifice to save our own?]

There’s a psychological experiment which has been conducted in many cultures. The results are always the same. [Sorry, it’s been years since I read about this, so details are hazy. But this is the gist:] IIRC, Twenty people are chosen at random. They line-up to receive a free lottery ticket. The holder of the winning lottery ticket will receive a prize worth $20 in the local currency. Drawing is to take place 5 minutes after the last participant has his/her ticket. Thus, each ticket has a numerical worth, prior to the drawing, of $1. The foregoing is known by all. Financial negotiations are secretly made with each participant to ‘opt-out’ of the lottery. IIRC, those who haven’t yet received a ticket ‘opt-out’ for less than $1.50. Those who now posses, but only moments before didn’t, a lottery ticket only opted out when offered more than $3.00. Just holding on to a ticket for five minutes doubled its subjective value.

[I think the producers of ‘The Price is Right’ knew of the experiment and added some ‘fun embellishments’. Production costs are much cheaper than having to employ actors; and even those costs are picked up by the companies which provide the prizes who, in turn, charge them off as tax-deductable advertising expenses. So enjoy the show. Your taxes are being used so that people can volunteer to make fools of themselves ].

dimkr is right. Puppy must keep pace with Linux’s evolution. Some version of Puppy must offer the potential of making use the best which Linux then offers. But, here, again Puppy has an advantage over other Linuxes. You don’t always have to choose. Each Puppy only requires its own folder. With Puppy you often can keep the ‘tested-and-familiar’ version you have while gradually undertaking whatever learning curve the ‘brand-spanking new’ Puppy may present.

Being able to upgrade glibc would extend that period of choice.

The project, see here: viewtopic.php?p=70584#p70584

[ozsouth]

@mikeslr - re-Bionicpup64 - I've pm'd you a security update .pet to try.

[mikeslr]

Thans, oz, for the pet. Will try it. And especially thanks for reminding me to check my email.

[amethyst]

@mikeslr

None of those Puppys are Puppys I now recommend to anyone unless their computer’s limitation compells it

I think I'm going to disagree with you on this. I can run the latest 32-bit and 64-bit Puppys on my machine yet I use and prefer my adapted Precise Puppy as my daily driver. Why shouldn't I, I can do everything I can do with a newer Puppy. I can even run the latest Palemoon browser. Besides the old Puppy runs much faster for me.

[mikeslr]

@ amethyst. You'd also make a lousy True-Believer.

[amethyst]

As an experiment I used the same initrd (with all the envoked additional drives) I use with all my 32-bit Puppys, with the only 64-bit Puppy I have and it still works. Attached a snapshot, you can see a bdrv loaded. This is what I love about Puppy, one can try all sorts of weird things and most of the time it comes off. Also just dropped in an old tahr64 kernel and it now boots like a house on fire. But enough of 64-bit, back to using 32-bit .

[Phoenix]

I don't think we should outright replace it using another core squashfile which will provide the newer libc.
And NO, you cannot willy nilly swap glibc's: glibc is backward compatible but not forward, you cannot use an application linked to libc 1.1 with libc 1.0.
Instead we should create the option to shim in the newer libc and use it with the application of choice.
An example:
glibc-a.sfs should be created to place its content in /opt and has a script to take an application and execute with it.
Squashfile should already be loaded in.
Squashfile should also link /etc/localtime in itself to point to /etc/localtime.
The script libc-shim:

Code: Select all

#!/bin/sh
/opt/glibc-a/ld-linux.so.2 --library-path /opt/glibc-a/:$LD_LIBRARY_PATH $1

The resulting profile to bring the script into path, located at /etc/profile.d/libc-shim-path in the squashfile:

Code: Select all

export PATH=/opt/glibc-a/bin:$PATH

This would do two things: It'd serve as a way to not break things (by accident) because now all applications that require a newer libc must use this script to shim in the newer libc. Next no matter how you decide you wish to mess with LD_LIBRARY_PATH the linker will ignore the variable, but the shell will substitute in after the /opt/glibc-a which makes it safer and prevents issues with random executables failing. (Although functionality might be slightly downgraded such as ls losing colors)
Next, applications cannot be compiled to the newer libc unless you explicitly say so, which will stop breakage if one decides to revert back to the system libc.

[amethyst]

I don't think we should outright replace it using another core squashfile which will provide the newer libc.
And NO, you cannot willy nilly swap glibc's: glibc is backward compatible but not forward, you cannot use an application linked to libc 1.1 with libc 1.0.
Instead we should create the option to shim in the newer libc and use it with the application of choice.
An example:
glibc-a.sfs should be created to place its content in /opt and has a script to take an application and execute with it.
Squashfile should already be loaded in.
Squashfile should also link ``/etc/localtime`` in itself to point to ``/etc/localtime``.
The script libc-shim:

Code: Select all

#!/bin/sh
/opt/glibc-a/ld-linux.so.2 --library-path /opt/glibc-a/:$LD_LIBRARY_PATH $1

The resulting profile to bring the script into path, located at ``/etc/profile.d/libc-shim-path`` in the squashfile:

Code: Select all

export PATH=/opt/glibc-a/bin:$PATH

This would do two things: It'd serve as a way to not break things (by accident) because now all applications that require a newer libc must use this script to shim in the newer libc. Next no matter how you decide you wish to mess with `LD_LIBRARY_PATH` the linker will ignore the variable, but the shell will substitute in after the `/opt/glibc-a` which makes it safer and prevents issues with random executables failing. (Although functionality might be slightly downgraded such as ``ls`` losing colors)
Next, applications cannot be compiled to the newer libc unless you explicitly say so, which will stop breakage if one decides to revert back to the system libc.

Should the glibc be loaded in /opt? This looks a lot like what is being done with portable applications in order to run newer applications with older Puppys (which is normally created/loaded outside of the running file system and then the library paths linked). So basically the old glibc are not removed with this method. Let's say we have the new glibc already extracted in a folder (not in sfs format) on the partition (so we have the glibc say in folder located at /mnt/sda3/gibc2.30). How would the library linking path script look then? Also in the latter case, since one then has the full newer glibc to ones disposable it may be easier to run more newer applications without having to do the library path linking for every specific application (ie. incorporating it into every new application individually). Is that correct...and I suppose one can then run the linking script automatically too at startup so that the new gilbc are readily available for use with newer applications?

[greengeek]

Should the glibc be loaded in /opt?

Or why not in a totally new filesystem directory such as /glibc or /exp (experimental)?
The Linux filesystem is already hairy enough so why not add an extra Puppy-specific node?

[amethyst]

Should the glibc be loaded in /opt?

Or why not in a totally new filesystem directory such as /glibc or /exp (experimental)?
The Linux filesystem is already hairy enough so why not add an extra Puppy-specific node?

I would prefer it to be totally out of the current running filesystem.

[mikeslr]

Because of the time constraints noted on this thread, I've downloaded S15Pup64-22.11-RC.iso, viewtopic.php?p=71041#p71041 and will put it 'thru its paces' before returning to this project. Consider it tabled for now.

[mikewalsh]

@amethyst :-

I would prefer it to be totally out of the current running filesystem.

Er.....huh??

You yourself have previously used /microemulator-2.0.4 as part of your Opera Mini package, under "/". I don't think greengeek's idea is so far off the mark, actually....after all, the Linux file-system is flexible enough to take this sort of thing in its stride.

Mike.

[amethyst]

@amethyst :-

I would prefer it to be totally out of the current running filesystem.

Er.....huh??

You yourself have previously used /microemulator-2.0.4 as part of your Opera Mini package. I don't think greengeek's idea is so far off the mark, actually....

Mike.

You seem to have a problem with me having used / as mounting for my extra sfs's in the past, so what? You are coming across as a bit snotty in this regard and I do not appreciate your attitude. There was no specific reason why all my sfs built extra files were loaded at /. It's just the way i used to do it (not that I owe you any explanation). You may be interested to know that I have subsequently got rid of many of these extra sfs files and they are now sitting "extracted" on my partition (out of the running filesystem). For instance, my windows programs were all basically in their own folders and were already basically "portable" applications". BTW - I asked you nicely on a previous thread which of your new 32-bit portable browsers you think will run on older Puppys like Precise. We know Palemoon and Seamonkey will but what about Iron and others, etc. I think Firefox and Chromium will be difficult. Since you have all these portables at your disposal, care to test it and comment?

[mikewalsh]

@amethyst :-

No, there's no "problem" at all. Sorry if it came across like that; no slight was intended. I didn't word my response too well!

I understand the concept of 'keep it out of the running file-system'.....but wherever you put it, it's got to be accessible by any application wanting to use it.....and those will be in the "running file-system". So there would have to be a "link" of some kind, even if it's only within a script of some description; we can't take for granted that everyone would have the same drive setup, for example. However it's constructed, obviously it needs to work with any standard Puppy layout. So.....

Maybe employ the same structure as I used with the portable chrooted Iron v69 I put together, when we were playing around with Darry's resurrected Puppy 431 a few years back? The entire chroot package - with Iron 'built-in' - was built to sit at & load from /mnt/home, outside of the Puppy 'save' structure (where an SFS would normally sit anyway, though here the entire chroot was intended to sit within a self-contained directory).....with a single sym-link to "/" for the purpose of linking the chroot into the main file-system. Launch commands were then routed through that sym-link.

(And yes, you did ask me about those browsers.....but this isn't the place to bring that up. If you post that in the Precise Extra thread, I'll be happy to answer - and explain why I haven't had a chance to try them out yet.)

Mike.

[amethyst]

@mikewalsh
No probs. Here is the question I asked about the browsers in the Precise Extra thread: https://forum.puppylinux.com/viewtopic. ... 528#p70528

[Phoenix]

Should the glibc be loaded in /opt? This looks a lot like what is being done with portable applications in order to run newer applications with older Puppys (which is normally created/loaded outside of the running file system and then the library paths linked). So basically the old glibc are not removed with this method. Let's say we have the new glibc already extracted in a folder (not in sfs format) on the partition (so we have the glibc say in folder located at /mnt/sda3/gibc2.30). How would the library linking path script look then? Also in the latter case, since one then has the full newer glibc to ones disposable it may be easier to run more newer applications without having to do the library path linking for every specific application (ie. incorporating it into every new application individually). Is that correct...and I suppose one can then run the linking script automatically too at startup so that the new gilbc are readily available for use with newer applications?

Since we're discussing modularization, or at least shimming in libc, /mnt/sda3/glibc2.30 is less than appropriate for modularization. But I don't really see how it's going to be handled besides use of version naming libc shim scripts and manually adding into profile.d directory to have it appear in path or creation of yet another configuration file and letting the user 'configure' possible options (paths), then creating one giant script that asks which one the user wants. (Bad)

On the topic of modularization the creator would write using this template script, appropriately modify to where the squashfile will appear in the filesystem and then version name the script to the same libc version. (libc-shim-3.2 for example)
Running newer applications is usually what's done if compiling from source would not be practical or impossible. For example, building with Rust, or the unpackaged size of everything including dependencies would exceed storage.
It's not intended to be run automatically, the user will need to manually invoke the script to stop issues with random failures. For example changing the library path, on my testing trying to run ls made the linker quit.

The reason for /opt is what it is used for traditionally and mostly aligning with FHS. Sure feel free to place it anywhere but that might be sometimes problematic.
As well the lack of chroot usage is intended so that you need not again, bundle anything else than minimal libc packaging and maybe an application with the extra libraries added in.

[amethyst]

Should the glibc be loaded in /opt? This looks a lot like what is being done with portable applications in order to run newer applications with older Puppys (which is normally created/loaded outside of the running file system and then the library paths linked). So basically the old glibc are not removed with this method. Let's say we have the new glibc already extracted in a folder (not in sfs format) on the partition (so we have the glibc say in folder located at /mnt/sda3/gibc2.30). How would the library linking path script look then? Also in the latter case, since one then has the full newer glibc to ones disposable it may be easier to run more newer applications without having to do the library path linking for every specific application (ie. incorporating it into every new application individually). Is that correct...and I suppose one can then run the linking script automatically too at startup so that the new gilbc are readily available for use with newer applications?

Since we're discussing modularization, or at least shimming in libc, ``/mnt/sda3/glibc2.30`` is less than appropriate for modularization. But I don't really see how it's going to be handled besides use of version naming libc shim scripts and manually adding into ``profile.d`` directory to have it appear in path or creation of yet another configuration file and letting the user 'configure' possible options (paths), then creating one giant script that asks which one the user wants. (Bad)

On the topic of modularization the creator would write using this template script, appropriately modify to where the squashfile will appear in the filesystem and then version name the script to the same libc version. (libc-shim-3.2 for example)
Running newer applications is usually what's done if compiling from source would not be practical or impossible. For example, building with Rust, or the unpackaged size of everything including dependencies would exceed storage.
It's not intended to be run automatically, the user will need to manually invoke the script to stop issues with random failures. For example changing the library path, on my testing trying to run ``ls `` made the linker quit.

The reason for ``/opt`` is what it is used for traditionally and mostly aligning with FHS. Sure feel free to place it anywhere but that might be sometimes problematic.
As well the lack of chroot usage is intended so that you need not again, bundle anything else than minimal libc packaging and maybe an application with the extra libraries added in.

So if the aim is to run many newer apps (which may require newer glibc) this will not really work as a wonder solution as each individual application will still need its specific depending libraries besides only the newer glibc to work (which may require additional lib files also when running on an older Puppy), is that correct? In this case, I do think the way mikewalsh is doing his portable applications is the better way to go. His method involves the files of the application plus the dependencies required to run on an older Puppy, running from a location "outside of the running filesystem" like I suggested in my post and then linking the library paths. He does this with Palemoon for example to be able to run a new version with old Piuppys. So it's basically a temporary linking setup but the linking scripts are also in the folder with the required application files but located "outside of the running filesystem" like /mnt/sda3 for example. So one may as well have the linking script included with every individual application as every application will have its own dependencies. I'm still going to experiment with my newer glibc loaded as a bdrv though (the same newer version loaded as a bdrv with all the older Puppys and the older glibc of the Puppys being removed). So far I have not seen any instability issues nor issues with builtin applications not running. My idea is to try a new application (packaged as an extra sfs file) used with all these older Puppys and include any other required dependencies (like additional libraries) in the sfs. I reckon including all the additional required libraries for the older Puppy which requires the most additional files may/could work in some/most cases. Precise Puppy may require extra lib1 and lib 2 files whilst Bionic may require only the additional lib1 file but nevertheless. Obviously some things will just not work as the jump from say Precise to Bionic is just too big even if they are using the same glibc.