Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 17 Apr 2014, 06:42
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
pUPnGO - 6Mb ISO - Basic Building Block Puplet
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 41 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 39, 40, 41, 42, 43, ..., 56, 57, 58 Next
Author Message
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Tue 10 Apr 2012, 15:21    Post subject: X11-tiny almost builds with musl  

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:
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.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 777

PostPosted: Tue 10 Apr 2012, 15:55    Post subject:  

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.
snap0001.png
 Description   and the thing running as it is now
 Filesize   120.13 KB
 Viewed   883 Time(s)

snap0001.png

xhippo-3.3-i486.pet
Description  static build of xhippo
pet

 Download 
Filename  xhippo-3.3-i486.pet 
Filesize  315.37 KB 
Downloaded  158 Time(s) 
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Tue 10 Apr 2012, 22:53    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Fri 13 Apr 2012, 01:50    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Fri 13 Apr 2012, 12:56    Post subject:  

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.cgi?p=musl;a=blob_plain;f=COPYING;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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Fri 13 Apr 2012, 21:37    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Fri 13 Apr 2012, 23:19    Post subject:  

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

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
PANZERKOPF

Joined: 16 Dec 2009
Posts: 279
Location: Earth

PostPosted: Sat 14 Apr 2012, 17:19    Post subject:  

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? Smile
Vga=normal means usual console without framebuffer but Xvfb needs ready framebuffer before starting.

_________________
SUUM CUIQUE.
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Sat 14 Apr 2012, 19:00    Post subject:  

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

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 __*.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Sat 14 Apr 2012, 21:16    Post subject:  

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

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Sun 15 Apr 2012, 00:47    Post subject:  

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).
Quote:
...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...
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Sun 15 Apr 2012, 20:41    Post subject: X11-tiny and struct sigaction  

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
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Sun 15 Apr 2012, 23:47    Post subject:  

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/openembedded-core/tree/meta/recipes-graphics/xorg-xserver
you might be interested in its i810 kdrive
or the pre kdrive removal commit
http://repo.or.cz/w/xorg-server.git/tree/7cabf81c8638739a15a1be6baa3fc569f38e7589:/hw/kdrive
though they may need some patching using this history as a guide:
http://repo.or.cz/w/xorg-server.git/history/HEAD:/hw/kdrive

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 429
Location: State of Jefferson

PostPosted: Mon 16 Apr 2012, 20:54    Post subject:  

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/openembedded-core/tree/meta/recipes-graphics/xorg-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)
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4133

PostPosted: Mon 16 Apr 2012, 23:14    Post subject:  

The kdrive stuff is there and you had to go into the subdirectory for the patches:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/xorg-xserver/xserver-kdrive-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)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 41 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 39, 40, 41, 42, 43, ..., 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1105s ][ Queries: 12 (0.0160s) ][ GZIP on ]