(old)Puppy Linux Discussion Forum

technosaurus wrote:...
@goingnuts - would you be able to push your toolchain to github or possibly a fossil repo on goingnuts.dk?
...

I will try but may take a while. Meanwhile below is the packages used to populate initrd: And the packages needed to make the core-pupngo sfs: Most of them builds static with P412 glibc/uclibc - but some of them needs patching.
Apart from that the kernel+modules and initrd+core-sfs file-skeleton including all the scripts.

I just saw a reference to dietxlib-0.04.tar.gz. I am unable to find a link to those sources. Any ideas?

They were here but seems to have vanished. I got the source (2.2Mb) if you need it.

Yes, please do make the source available somewhere -my email account is fine for that, even. You know how I collect oddities...

amigo: Send to you by mail.
How about a simple spreadsheet - like The abs Spreadsheet? Builds to approx. 1Mb static linked bin with tinyxlib-4.8.0 & uclibc.

dietxlib published...
Works with a standard Puppy-412-devx dietlibc (v0.31?) and enable you to do quite tiny static linked X11 binaries.
Ex. 9menu compiles to 79Kb (make -f Makefile.noimake CC="diet gcc -Wl,--gc-sections,--sort-common,-s").
dietlibc has recently (20130312) released a new version - I haven't tested that but dietxlib-0.06 works with the previous version 0.32.

Exercising tinyxlib-4.8.0 - which is a tinyxlib born from patched full source of XFree86-4.8.0.

In the image below running 3 different bins of xcalc: Left is normal dynamic linked bin - middle is xcalc from tinyxlib-4.8.0 but merged with 9 other xutilities (xconsole xfontsel xload xmessage xvidtune xclipboard xcutsel xgamma xman) in a multicall binary - and right is single static bin from tinyxlib-4.8.0.

The mcb use 230Kb (or +25%) more memory than the standalone bin - but still only 26% of the memory the dynamic linked bin use.

Hey -- I don't know how earth-shatteringly nasty this is, but a friend of mine found a bug in ldso that (if I'm reading this correctly) affects uClibc, among other things -- which I seem to recall that someone was proposing to use in pUPnGO at one time.

Maybe this is why it didn't work out that way? (or, it's a big nothing and I can't read... that *is* possible, lol)

http://lists.uclibc.org/pipermail/uclib ... 48221.html

EDIT: also, at his request, here's my friend's website, with some uClibc dev stuff (a pair of chroot build environments) on the front page... nifty, if you know what to do with them

http://c02ware.com/index.php

starhawk: Thanks for the info - the bug thing is way over my head - but the tool chain I might understand - downloading for testing.

Here's an update, looks like my guru friend has things fixed, at least in a quick&dirty way...

http://lists.uclibc.org/pipermail/uclib ... 48222.html

I'll let him know you're checking out his toolchain

Probably should redownload that toolchain, sorry -- Jody only pushed that fix through to c02ware a few minutes ago

@goingnuts the mcb will use less on newer kernels due to copy on write improvement ...for each extra process

Edit: I recently revisited my alternative to the 'file' program for getting mime types (and the alternative xdg stuff that rox filer uses) and have significantly improved performance and added type deduction by magic values. I was thinking about patching rox to use it, but I also thought it may be good for rox to fallback to using the extension if its mime type is not handled.... for instance if a .dummy file is clicked it first tries to run application_dummy , but should also try running 'dummy' if it is application/unknown or application_dummy is missing. Any thoughts? If it matters, I have been using rox-0.1.39 mostly, due to its lighter weight, but this part should be compatible with later versions (it does add ~30kb to the binary for the sorted extension tables, but it is 99% constants) I am also patching it to use builtin xpm images for the toolbar and parent mime types (such as image, text, inodes, application, audio, video...) so that it can just be dropped and run anywhere without a bunch of extra files

technosaurus: Might be that it should run a build-in universal file-viewer if unknown? Any links for the rox-0.1.39 source? I definitely like all your patch goals - much appreciated. Any chance of build-in check if an application needs a terminal to run (sometimes an application causes X to freeze or starts a 100% cpu usage in the background)? Might be worth to maintain the original behavior as well (ex: external images for toolbar).

The mcb is quite convenient for Xaw-hungry apps in terms of keeping size and memory usage down. Found that xman is really handy when offline - xcalendar-3.0 and xalarm-3.06 seems usefull to include in the basis X-environment too. And some of them can be "themed" to look quite nice.

I have been working on getting gtk2 running in pupngo - as static linked apps and using uclibc. Some sort of breakthrough using glib-2.16.6+atk-1.22.0+cairo-1.6.4+pango-1.20.5+gtk+-2.12.12...

The libs gets installed and simple apps like editor compiles error free.
Then if run in P412 they segfaults - I accidentally run one of them from within my chrooted toolchain - and after a while it suddenly turned up on the desktop. A strace pointed the segfault to happen when gtk-theme should load (pixman.so call). The app launched from within the chrooted environment used standard theme (Raleigh the only theme installed there) but desktop used Gradient-gray which include image handling. Changing desktop theme to Raleigh made the app launched directly work.
Now - how could an app launched from a chrooted environment find my desktop outside the chroot and show itself?
I am running Xvesa and the standard P412 xwin does not add "-nolisten tcp" to Xvesa parameters. If I introduce "-nolisten tcp" the app launched from chrooted environment does not show up but gives this message: The static linked binary is quite big - fx. isomaster-1.3.13 is 5807K and theme cannot contain images - but beside that - might make it possible to create some of those apps which is hard to get if gtk2 is not supported.

Hi goingnuts

I am not sure but a read here may help
https://wiki.archlinux.org/index.php/Change_root

Further down see : "Run graphical applications from chroot"

@partsman - thanks for the link. chroot expose every env set by root - good to know.
Turns out that static linked gtk2 bins are slightly more complex than I hoped: glib2/gtk2 internally loads external dyn libs so some functions has to be patched out

In your chroot you'll need /tmp/.X11-unix/<display>
Note that you can use env -i var=val ... <command> to pass the exact env vars that you want.
You can run a separate Xserver like xnest so that it comes up in a window.
It's good for testing various window managers/desktop settings for lower resolutions.

Where is the download link?
I want to try to make a remaster that is very minimal size iso.
Thank you

Try here:

https://archive.org/details/Puppy_Linux_pUPnGO

Keef wrote:Try here:

https://archive.org/details/Puppy_Linux_pUPnGO

also available at:
http://pupngo.dk/

and the source available at:
http://pupngo.dk/xwinflpy/xwoaf_rebuild.html

I was thinking it would be cool to put all this into an initial ram disk. Not sure why one would would need this yet but would like to learn.