Puppy Linux Discussion Forum

[technosaurus]

Wondering whether or not to recompile a program in your puplet to eliminate large shared libs that are only used once or twice

[technosaurus]

Reserved compile techniques.

In case you ever wondered whether or not to set certain flags, it is helpful to know which ones already are set. This can be done by:

[technosaurus]

Shrinking files.

[technosaurus]

Boot speed.

[technosaurus]

X

[technosaurus]

Alternative apps/libs

[technosaurus]

Kernel configs

[technosaurus]

Portability

[sunburnt]

Hi technosaurus; I wondered if this could do a statistical analysis of lib. usage in common apps.
I did a sudo analysis myself that showed a small percentage of libs. are actually in common use.

This is all about rules for which libs. to include in static builds.
Once the libs. are identified, then scripts for statically building them.
I don`t know if a build script "scrap" can be used many times like this.

[scsijon]

Technosaurus, I wonder if a common lib could be built, something on the Busybox basis?

It should shrink the overall size a bit!

[disciple]

FWIW there was a project to build GTK and X and stuff all into one binary... but it seems to be dead.

[technosaurus]

Goingnuts and I have done several x11, xaw and gtk1 apps as multicall binaries.... Gtk2 apps tend to use plugins - thus requiring significant patches... However there is an in between method where you mix static and dynamic libs based on analysis of dependencies. It gets complicated when you have to build pic versions of static libs so they can be statically linked into plugins (like png for imlib) and further complicated if you have another app that links to those libs directly (such as jwm with png support) requires changing the build to link to the imlib plugins for jwm. This is fine if you are doing a 1 time build of an embedded system with limited resources, but a royal pain to maintain for a distro. Thus the reason we hand picked a few compatible apps (sometimes even specific versions) and limited them to the minimum functionality needed to use/build/rebuild a system either from scratch using any distro's packages or so that if your whole shared library system gets corrupted, you can still recover comfortably with an intact desktop environment and still do basic everyday tasks like editing text, browsing the web or your file system, answering email and of course wasting time even if your libc gets corrupted.

[sunburnt]

I see no point in BusyBox in Squash file based O.S.s.
It just ends up being double compressed, usually with little improvement.

And here at Puppy we know BusyBox commands just don`t measure up.
Thought it could be compiled with full spec. commands...

BusyBox is a good idea for loose file systems, but not Squash file ones.

[disciple]

[technosaurus]

The advantage of statically compiling a multicall binary is that unused functions get compiled out. Busybox also has the capacity to "prefer applets" and call them as a function or by forking itself (both are much faster than running a separate binary... even moreso if that binary has to find and load shared libs) the only compression is the help text. Really it wouldn't hurt much to put a full busybox in the initramfs and copy it over. The only reason busybox applets sometimes fail is because the scripts weren't specifically written for it (tinycore scripts all work because they were) But I did notice that upx slows busybox down and the extra compression is negligible.