Need a small CD-player? Attached two different:
* cdtool-2.1.8 which also include tools for getting cddb output.
* dcd-0.99.2 - a more simple player.
Both need the hardware cabling from your CD/dvd-drive to your soundcard/motherboard being present...and remember to un-mute CD in audio mixer and turn up the volume as well...
Both might be handy back ends for a gtkdialog gui-frontend

After making the gtkman for gktdialog1 I tried to run it in pupngo. But found that although man-bin is static build it wont work. Turns out that man depends on at least tbl and nroff which in turn depends on different auxiliary macro-files.
All that just to view a man page that is "readable" by command "cat"...
tbl is quite easy to build static but nroff did not turn out easy. They belong to GNU groff-package which I did not manage to do a normal build of. Another source is The Heirloom Documentation Tools - all c-code and state that build with diet libc can be done. I tried diet but my version is 0.31 and I think it needs at least version 0.32 of diet libc (needs wctomb). But I managed to hack my way to a final static build of tbl and nroff - just to realize that although working they seems not to work well with man-expectations - some demand of -mandoc that I was not able to fullfill.
Btw. busybox man also needs tbl and nroff/troff/groff (it needs gtbl which is a symlink to tbl).
Another solution here. awf is a man-page formatter based on awk-macros and it does a decent job!
A third solution is to use the man2html - which is a standalone app with no need for auxiliary progs - and then use sed to remove the HTML-tags. man2html is part of the original man page.
The forth solution is to use sed on the raw man-page as well (guess awk would work too).
So ended up with a draft for gtkman version 0.2 where at least the sed-only and the man2html method gives reasonable output in pupngo - but with a lot of room for improvement...Maybe a project target for some sed -or awk-sharks?
The present draft code below:

Code:

#!/bin/ash
#simple demo for gtkdialog1 to view text formated man pages
#May 2012 goingnuts
#v0.1 needs original man - will not work with busybox man
#v0.2 liberate it from the man bin/use other ways...
#depending on the system one of the below will be used:
VIEW_ME=4 #simple sed - improve it please!

As per our previous discussion on reducing xpm images I finally got around to patching mtpaint to support saving xpm images with 92 colors per character vs 64. It makes for a bit nicer looking reduced images, and also bumps support for over 8000 colors vs. ~4000.

PANZERKOPF: Thank you - that are some nice findings! The cdplayer from asm-toys compile to less than 5k and have all functions to control and report status Wish assembler was easier to learn...as most assembler progs for linux I have seen are a factor 5-10 smaller than the normal...some examplestechnosaurus: I havent tried newer jwm (tried 562 but could not compile it) so below jwm is the usual patched jwm-2.0.1-pe-beta-1:

PANZERKOPFas most assembler progs for linux I have seen are a factor 5-10 smaller than the normal

Not only for linux. Assembler progs are always faster and smaller than same written in other language but have one big disadvantage: they are not portable.
Also, If you like assembler, play with KolibriOS. Really cool _________________SUUM CUIQUE.

Assembler progs are always faster and smaller than same written in other language.

assuming the coders are equally competent ...

So, I have been doing static compiles with my musl toolchain and I have gotten to some stuff that uses gdk-pixbuf-1.0.
@goingnuts - How did you grok the static compile of gtkdialog1 so that the gdkpixbuf stuff worked?

Edit: nevermind the configure script improperly set:
#define USE_GMODULE 1
... commented it out and works fineLast edited by technosaurus on Fri 08 Jun 2012, 00:45; edited 1 time in total

Ibidem: Thanks for the patch - I try it out.
PANZERKOPF: Yea - its quite impressive - this Kolebri!
technosaurus; Ok - glad you made it! Have you plans to post your tool-chain/build-script/sources at some time?

doing a static toolchain, you find a lot of bugs that go unseen otherwise... I am just trying to narrow down the issues to the appropriate place - usually it is autoconf
for gdk-pixbuf --disable-modules _should_ undef, not #define USE_GMODULE 1
(removed support for libtiff while I was at it - its just larger than it is useful)
I am trying to set up things as much as possible to allow people to use the toolchain without having to learn the intricacies of gcc ( I'm adding appropriate flags in a wrapper script - the included one has a couple of issues that require constant patching of makefiles ... sometimes libtool or autotools ignore CC=musl-gcc and CPP="musl-gcc -E" amongst other things and I figured I may as well hard code in all of the safe optimizations and necessary defines while I was at it)

I have also patched tinyX11 to some extent, but if you have your patched sources still, it would help (right now I have threads and NLS disabled and minimal utf8 in order to build - it seems that the sources from xfree86-4.8 work fine - just a lot of cut and paste)

I also got a cutdown freetype, openjpeg, jpeg, jbig2dec and z libs from mupdf (they have a nice build script for them) ... only read support so it worked well with gdkpixbuf and failed on mtpaint (so i built with only xpm and png) anyhow gtkdialog1 is working with jpeg support now._________________Check out my github repositories. I may eventually get around to updating my blogspot.

Sound really cool! I still have some gtk-apps that build fine dynamic and static but wont run in the static version (gtksee-0.6.0b-1) or run and fail at some point (chbg-1.4) that would be nice to have...
PM-ed link for dl of my current sources.

doing a static toolchain, you find a lot of bugs that go unseen otherwise... I am just trying to narrow down the issues to the appropriate place - usually it is autoconf
for gdk-pixbuf --disable-modules _should_ undef, not #define USE_GMODULE 1
(removed support for libtiff while I was at it - its just larger than it is useful)
I am trying to set up things as much as possible to allow people to use the toolchain without having to learn the intricacies of gcc ( I'm adding appropriate flags in a wrapper script - the included one has a couple of issues that require constant patching of makefiles ... sometimes libtool or autotools ignore CC=musl-gcc and CPP="musl-gcc -E" amongst other things and I figured I may as well hard code in all of the safe optimizations and necessary defines while I was at it)

I have also patched tinyX11 to some extent, but if you have your patched sources still, it would help (right now I have threads and NLS disabled and minimal utf8 in order to build - it seems that the sources from xfree86-4.8 work fine

If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.

If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.

CPP is the preprocessor (the thing that handles all of the macros/includes/etc...) - in a gcc tool chain usually this is just gcc -E, but in order to force it to look in my musl toolchain and not the standard directories I tell it to use my make shift wrapper built on the musl wrapper (just a script named gcc that calls gcc-real with appropriate defines and flags, yes I renamed gcc and called the wrapper gcc to save a helluvalotta editing) that prevents most of these broken scripts from doing the wrong thing. The issues aren't necessarily with musl, but I am having to add a few includes here and there or add -D_GNU_SOURCE or similar, but I am just going to add those to my wrapper script and maybe every once in a while add a symlink for a missing include like io.h (but most are kernel headers that just got missed or were overwritten by glibc)

After I have done a run through all of the useful C libraries on this toolchain without threads and locales, I will do a try with a native toolchain and try them out. (I just wanted to minimize my patching on the first run - its less overwhelming that way)

*question???
What is the best way to get a disk image onto a really low resource computer using minimal ram/cpu, but also not really long or complicated. I was thinking of piping an xz compressed tarball of a filesystem image through dd. However I am hesitant to do it that way due to the possibility of broken pipes (the plumbing is not always in good in these old beasts)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

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