pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

X11-tiny almost builds with musl

#601 Post by Ibidem »

I'm playing around with getting X11-tiny to work with musl[1].
Mostly it's a matter of substituting the right CC, -I.../include, and so on.
(musl provides a wrapper known as musl-gcc that's fairly effective at building stuff properly, without changing things behind your back--usually, make CC=musl-gcc is enough).

So far, build fails on Xfbdev and Xvesa but builds the libraries. I think this is just missing vm86 stufff.

[1] Musl is a libc that's aimed at minimizing footprint while providing a fully standard library with stable ABI--see http://www.etalabs.net/musl/
libc. I've gotten static busybox 1.18.5 binaries at around 800-900k, IIRC-don't reember whether that was stripped.

Code: Select all

ls -l libc.a
-rw-r--r-- 1 root root 1553870 2012-04-03 16:17 libc.a
And there are no extra libraries, unlike glibc.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#602 Post by goingnuts »

Ibidem: Sounds good - I did try to use musl as well but think I was not patient enough...
If you can get Xvesa build using musl and tinyX11 it will be very interesting to compare the size of the final bin with the one obtained using uclibc.

I have been looking for a GUI front end for minimp3 for some time. Started to build one myself using the gtkdialog1 backport...But today I was looking for some other stuff at amigos comprehensive collections of gtk1 goodies - and found xhippo.
Even though designed for mpg123 and friends it can use a symbolic link to minimp3 (named mpg123...).
We might spice the GUI up a bit - I think it could use some image-buttons - but might be another day. Attached a pet with a static build of xhippo.
Attachments
snap0001.png
and the thing running as it is now
(120.13 KiB) Downloaded 980 times

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#603 Post by technosaurus »

I have done builds with eglibc, uclibc, dietlibc and musl. Of those, uclibc is by far the most coverage for its size (eglibc is not much smaller than glibc ... just better and will compile with -Os without my glibc-Os patch, but now that Ulrich Drepper is out of the lead, I suspect sanity to prevail and a remerge ala Xorg and compiz) The only issue with all of these is the lgpl or gpl (dietlibc) license that makes our multicall binary strategy legally problematic ... so I am planning to build from here:
http://code.google.com/p/gentoo-bionic/downloads/list
at one time bionic did not have wchar support, but I think that may no longer be the case (gtk need wchar) ... and then rob's toybox to replace busybox and we can build the whole system as a multicall binary without having to think too much about the boring stuff.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#604 Post by Ibidem »

There's a bit of sed to change the compiler to musl-gcc; it's also critical to change some of the includes.
When building tinyX11, I kept getting errors like "could not find Cl".
I figured out that the command line is too long: using echo *.o |xargs ${CMD} instead of ${CMD} file1.o file2.o ... fixes this.
__[gu]id_t need the leading underscores removed for proper behavior.

And there's one show stopper ATM: no sys/{vm86,io}.h is provided. That may be on the way, though.
musl is currently LGPL with BSD parts, but Rich Felker decided that 0.9.0 will be BSD-licensed.
musl has wchar and co.
I'm working on adding _BSD_SOURCE macros to the headers, partly so that toybox will build without -D_GNU_SOURCE (see Rob's comments about defining _ALL_HAIL_RICHARD_STALLMAN)
One big advantage over uclibc is a stable abi-you can take nonthreading binaries linked to 0.7.x and run them with 0.8.7 or later. This makes for easier upgrades on any nonstatic system.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#605 Post by technosaurus »

I will try to provide a patch for those (either by adapting from a bsd or bionic) if/as soon as rich changes this: http://git.etalabs.net/cgi-bin/gitweb.c ... NG;hb=HEAD
Sounds like Rob (or someone on his behalf) put a bee in his bonnet ... it really wasn't filling any unfilled niche as a smaller lgpl licensed c library, but as BSD it could really gain some steam. I didn't have great success with the musl gcc wrapper before, so I ended up rewriting it (a native compiler would be better if you could point me to one or even the tools to build it properly) ... now to find a smaller BSD-ish replacement for jwm than enlightenment16 (currently looking at windwm 1.4, but it is not a full replacement) I am probably going to convert my sdialog program over to build with libagar instead of (or in addition to) gtk, so we have a permissively licensed gtkdialog/yad/zenity/xdialog replacement.

If all goes well with musl that will render most of my idea to combine all of the essential lgpl libraries into a single shared library moot (though I still may combine v1.2.x of glib,gtk* & gdk*) This would reduce the size (both library size -due to optimizations and ram usage -due to less dirty pages and elf garbage ) as well as speed up starts since less libraries will need to be dynamically loaded.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#606 Post by Ibidem »

He heard the discussion about toybox, thought there was something to Rob's comments, and asked the ML to vote on the license. It ended up being 7-8 in favor of MIT/BSD/... vs about 3 or 4 in favor of different variants of LGPL. So 0.9.0 will switch the license; 0.8.8 is close to release.
He has rewritten the wrapper a couple times, IIRC.

Do you mean sys/vm86.h & sys/io.h?
He is strongly opposed to exposing __* macros/functions/types, FWIW.

I build musl, then I can either just use musl-gcc with -static or build GCC (I use a slightly patched 3.4 because 4.x has some crazy choices about optimization; Rich is now using 4.6; and PCC, TCC, and Clang compilers also are known to work with musl).
I've found the most functional approach to bootstrapping musl to be roughly what the documentation suggests: convert a minimal development chroot in place; you need a static shell for this to work right (chroot won't work unless the shell can get it's libs beforehand).
You can also do a parallel install, though.

My sequence is about like so:
musl; binutils; gcc; musl (this is just testing);
busybox; ncurses; oddball libs;
dev tools.
Should probably rebuild gcc & binutils after musl-pass2...but really, only the rebuild of gcc is needed.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#607 Post by technosaurus »

I didn't plan to patch musl for vm86/io (I agree with Rich), just the stuff needed for xvesa/xvfb - possibly by adding a stub(s) to tinyX11 or sanitize the code itself.

That brings up a long standing question that I have had though - What universal parameter can we pass to the kernel so that xvfb will start on all supported systems ... something like vga=normal is coming to mind??? this has been broken in puppy for a while AFAIK, but I think there is a way... I'd like to use xvfb vs. xvesa by default to better support arm
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#608 Post by PANZERKOPF »

technosaurus wrote: What universal parameter can we pass to the kernel so that xvfb will start on all supported systems ... something like vga=normal is coming to mind???
Maybe vga=ask is that universal parameter? :)
Vga=normal means usual console without framebuffer but Xvfb needs ready framebuffer before starting.
SUUM CUIQUE.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#609 Post by Ibidem »

technosaurus wrote:I didn't plan to patch musl for vm86/io (I agree with Rich), just the stuff needed for xvesa/xvfb - possibly by adding a stub(s) to tinyX11 or sanitize the code itself.
xvfb? That's the virtual framebuffer port--it's only relevant for running X headless. I assume it's Xfbdev you mean. ;-)

You won't get vesa without vm86 (unless you port to libx86, which adds a library and is slower because it emulates i86--or uses vm86 if possible). Also, I think I've convinced Rich to add vm86 (it's also needed for stuff like dosemu, vbetool,...). Vesa is based on the BIOS.

lnx_video.c and linux.c are the problematic places, FWIW.

I'm wanting Xvesa for stuff like i810, where there's no framebuffer (I have an old Dell Dimension L800r, with ~128MB RAM, 800MHz PIII, and...i810 graphics).

It's stuff like __uid_t that I referred to when commenting on __*.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#610 Post by technosaurus »

yeah, xfbdev... looks like there is no "automagic" mode, but I figured out where to (attempt to) patch the kernel to autoselect the mode arch/x86/boot/video.c ... rather than having to have vga=ask and then the user try to figure it out manually or using "scan" (hopefully qemu is sufficient for testing it - but I'll definitely need to reconfigure my minimal Xvesa qemu kernel ... hope it doesn't push my desktop image over 1MB, since I eventually want it to fit in a coreboot payload ... if it does I'll have to patch and replace png and jpeg with stb_image or something )

...re vm86: it doesn't matter if the vm86 stuff is in the libc or some other library or even a separate .o that can be statically linked in though ... dietlibc separates out the "ugly" stuff in this manner IIRC
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#611 Post by Ibidem »

technosaurus wrote:yeah, xfbdev... looks like there is no "automagic" mode, but I figured out where to (attempt to) patch the kernel to autoselect the mode arch/x86/boot/video.c ... rather than having to have vga=ask and then the user try to figure it out manually or using "scan"
For some reason, I seem to get proper resolution without hacking here (on framebuffer driver load).
...re vm86: it doesn't matter if the vm86 stuff is in the libc or some other library or even a separate .o that can be statically linked in though ... dietlibc separates out the "ugly" stuff in this manner IIRC
Sounds OK, as long as it is actually x86 vm86, not emulation.
Speaking of which--grep thinks that dietlibc doesn't implement vm86 ?? (only the headers contain that string).
io.h stuff seems to be done in asm there...

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

X11-tiny and struct sigaction

#612 Post by Ibidem »

Apparently, the lines in programs/Xserver/hw/kdrive/linux/linux.c containing:

act.sa_restorer = 0;

are superfluous.
Rich Felker wrote:This is definitely wrong and unnecessary. If it were necessary, it would be impossible to write portable programs using sigaction. The reason it's unnecessary is that even libcs that use sa_restorer require the SA_RESTORER flag to be set in order to use it; otherwise it's ignored.
And Xorg simply removed the aforesaid line about 8 years ago.
So that should be safe.

That and __[gu]id_t are the primary differences, besides vm86.h & io.h

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#613 Post by technosaurus »

yeah, I am planning to try a newer version anyhow ... one that openembedded has been using ... with a couple more kdrives:
http://cgit.openembedded.org/openembedd ... rg-xserver
you might be interested in its i810 kdrive
or the pre kdrive removal commit
http://repo.or.cz/w/xorg-server.git/tre ... /hw/kdrive
though they may need some patching using this history as a guide:
http://repo.or.cz/w/xorg-server.git/his ... /hw/kdrive
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#614 Post by Ibidem »

technosaurus wrote:yeah, I am planning to try a newer version anyhow ... one that openembedded has been using ... with a couple more kdrives:
http://cgit.openembedded.org/openembedd ... rg-xserver
you might be interested in its i810 kdrive
or the pre kdrive removal commit
...
Well, those two are "Modular Xorg"...and I've been hoping to get a little before that, though I could probably hack up some scripts...
Either way I'd need to handle sys/io.h, because that's needed for X to work on Linux (except, apparently, for xfbdev ?...which isn't viable for the platform, or as a longterm solution)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#615 Post by technosaurus »

The kdrive stuff is there and you had to go into the subdirectory for the patches:
http://cgit.openembedded.org/openembedd ... e-1.7.99.2

For a while Xorg had all the kdrives too, that link was the commit just before the great kdrive purge (I compiled them all a while back around that time for puppy 4) ... if you really look around you can find a couple of extra ones as patches that never made it into either the Xorg or the xc tree (xfree86) ... tinyx11 and uclibc can be used there just as well but I know dietlibc had several issues (even I gave up on it), so I would suspect musl would get a few hiccups at least at first. One thing to think about though is that the kdrive and the xorg module for each card should be almost templatable, so you may be able to grok patches based on the xorg module (or if you really want some fun, port an xorg module into a kdrive from scratch) I'd be interested to see how well the SDL driver works compared to xfbdev (are there devices where SDL would work without a framebuffer? otherwise, why use it indirectly ... puzzling ... now opengl based I could see)... I had better stop here before I get into speculation about the possibilities with opengl and llvm bytecode (one pre-binary for all platforms ...from arm to x86_64 that JIT compiles to fully native machine code with all cpu & gpu support)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#616 Post by technosaurus »

I just grokked my jwm_menu_create code to work with 9menu, so now we have a window manager independent application menu.
http://www.murga-linux.com/puppy/viewtopic.php?t=77660
still todo? - gtkdialog1 version
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

r4m0n3
Posts: 10
Joined: Tue 06 Jan 2009, 22:57

#617 Post by r4m0n3 »

Hi all!
This is nice project and it´s great to follow the development.
Id like to "build" on this too but my expertise is on a level where adding stuff isn´t that simple without installer. pkg-inst_rmv.pet would help I guess, but how do I get to use it first?

I´ve been also wondering what it would take to use pUPnGO on a touch screen computer (7" and limited resources)? Referring to my skills, would you suggest a puplet created for this use or would it be worth trying with this one (anyone done it already?)

cheers

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#618 Post by goingnuts »

r4m0n3: pUPnGO does have the cli "pkginstall.sh" which will install tar.gz, tcz, pet, sfs, tgz, rpm, deb and gz.
So you could pack the pUPnGO iso with all the packages you need and install after boot.

Concerning the touch screen I have no clue - never worked with that - but sounds like real fun!

I have worked a bit further with xhippo. It turns out to be a quite mature. Fixed dnd for files with spaces (most of my mp3 files are with spaces...) and added icons. Went to last version 3.5...after that the author seems to be focused on potamus which is much more gtk2ish. Attached image of the present state of the modified xhippo and a static build. Pm me if you need the patches.
Attachments
snap0001.png
(17.65 KiB) Downloaded 1178 times

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#619 Post by technosaurus »

for touchscreen to work we would need to rebuild xvesa with tslib - There are patches @ my previous link
Edit: you'd also need an app like xvkbd or svkbd (would be a good idea to add these to an mcb build with a tslib patched xvesa)

NEWS: I have been working on simplifying the entire directory tree for speed, compatibility and size. Part of this just involved making redundant directories into symlinks (this speeds up, for example, PATH and LD_LIBRARY_PATH searchs, since there is only 1 to search), but recently I have been flattening the kernel module directories into a single directory. This has showed better results than I even expected: ~20% size reduction, huge performance boosts for modprobe, depmod, etc... Although it simplifies parts of coding, there _is_ existing code that does depend on the directory structure being in place - (dougal's /usr/sbin/updatenetmoduleslist.sh for example) ... so far everything has been pretty easy to patch.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#620 Post by goingnuts »

...~20% size reduction, huge performance boosts for modprobe, depmod
How? A quick test in pUPnGO showed equal size of zdrv-sfs for flat and normal directory-structure of the modules. A timing (in qemu...) showed very equal performance of running depmod -a.
Using build in "modules.*" in the zdrv skips the need for running depmod at first boot which gives faster boot than running depmod...
The "modules.*" weight around 1,3Mb unpacked but only around 120K packed. What am I missing to benefit from your findings?

Post Reply