pUPnGO - 6Mb ISO - Basic Building Block Puplet
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
before you do, you should set up a paypal account for tipsgoingnuts wrote: I wonder...if I stripped goingnuts...would it be the going or the nuts that got smaller..?
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].
- RetroTechGuy
- Posts: 2947
- Joined: Tue 15 Dec 2009, 17:20
- Location: USA
From coconuts, down to pine nuts...goingnuts wrote: I wonder...if I stripped goingnuts...would it be the going or the nuts that got smaller..?
[url=http://murga-linux.com/puppy/viewtopic.php?t=58615]Add swapfile[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]
Thank you for your support for the above strictly hypothetic question about stripping and goingnuts...
Hard to pickup with some boring stuff but I will give it a try:
Some time ago I made a mcb holding the following programs (the cdrecord and mkisofs being symlinks to wodim and genisoimage)
I later found that mksquashfs4.0 is not needed if you have mksquashfs3.0.
When trying to rebuild it failed - as I have later changed my uclibc - from buildroot environment to standalone uclibc.
The problem is the cdrkit which is a pain to build. So looked at alternatives and got an interesting tour in history with the cdrkit versus cdrtool. Found an early source of mkisofs (mkisofs-1.12b5) giving a clear build with uclibc only 78K static. But it misses some functions. So looked at the cdrtools (cdrtools-1.10) but as with cdrkit the build is a pain. I guess those build systems that seems to haunt the cd-packages has a purpose but I wish they also was shipped with an ordinary configure&make opportunity. Btw. cdrtools-1.10 gave me a 180K cdrecord and a 286K mkisofs static build (versus cdrkits wodim 322K and genisoimage 618K). No doubt some newer features is missing but I only need it for the save-pup-to-cd/dvd...
Update: I was a little to quick above: The 1.10 cdrecord wont support my writer and a build from the 2.01 version only supports cdrw and not dvd. But at least the mkisofs works and saves some 300K...
Hard to pickup with some boring stuff but I will give it a try:
Some time ago I made a mcb holding the following programs
Code: Select all
cdrecord genisoimage growisofs mkisofs mksquashfs3.0 mksquashfs4.0 wodim
I later found that mksquashfs4.0 is not needed if you have mksquashfs3.0.
When trying to rebuild it failed - as I have later changed my uclibc - from buildroot environment to standalone uclibc.
The problem is the cdrkit which is a pain to build. So looked at alternatives and got an interesting tour in history with the cdrkit versus cdrtool. Found an early source of mkisofs (mkisofs-1.12b5) giving a clear build with uclibc only 78K static. But it misses some functions. So looked at the cdrtools (cdrtools-1.10) but as with cdrkit the build is a pain. I guess those build systems that seems to haunt the cd-packages has a purpose but I wish they also was shipped with an ordinary configure&make opportunity. Btw. cdrtools-1.10 gave me a 180K cdrecord and a 286K mkisofs static build (versus cdrkits wodim 322K and genisoimage 618K). No doubt some newer features is missing but I only need it for the save-pup-to-cd/dvd...
Update: I was a little to quick above: The 1.10 cdrecord wont support my writer and a build from the 2.01 version only supports cdrw and not dvd. But at least the mkisofs works and saves some 300K...
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
* 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
- Attachments
-
- cdtool-2.1.8-i486.pet
- static build CLI CD-player + other CD-utilities
- (68.82 KiB) Downloaded 470 times
-
- dcd-0.99.2-i486.pet
- static build CLI CD-player
- (19.2 KiB) Downloaded 457 times
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:
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: Select all
#!/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!
[ $(which awf) ] && VIEW_ME=3 #view http://awk.info/?tools/awf
[ $(which man2html) ] && VIEW_ME=2 #part of org man pkg
[ $(which man) ] && [ $(which tbl) ] && [ $(which nroff) ] && VIEW_ME=1 #for systems with all it takes for man to work
echo "Using methode $VIEW_ME" #just to know what is going on...
#hardcode mandirs...
MANDIRS="/usr/share/man /usr/man /usr/local/man"
echo > /tmp/gtkman
#create list of man-files present in system
COMBOLIST="<item>Select page to view</item>"
#v0.2
mandirs=$(find ${MANDIRS} -type f)
for file in $mandirs; do
name=$(basename ${file})
name=$(echo ${name%.*}) #for .gz
name=$(echo ${name%.*}) #for .1
COMBOLIST="$COMBOLIST<item>$name</item>"
done
#ash function file
echo '
view_me1 () {
man -P cat ${1} 2> /dev/null | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
}
macro_2 () {
sed -e "s/<[^>]*>//g" | \
sed -e "s/\</</g" | \
sed -e "s/\ / /g" | \
sed -e "s/\>/>/g" | \
sed "/^$/d"
}
view_me2 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | man2html | grep -v "Content-type: text/html" | macro_2 > /tmp/gtkman
else
man2html $manfile2view | grep -v "Content-type: text/html" | macro_2 > /tmp/gtkman
fi
fi
}
view_me3 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | awf -man | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
else
awf -man $manfile2view | sed "s/.`echo -e\\\b`//g" | sed "s/.^H//g" | sed "s/.\x08//g" > /tmp/gtkman
fi
fi
}
macro_4 () {
sed "s/.B //g" | \
sed "s/.I //g" | \
sed "s/.TP//g" | \
sed "s/.PP//g" | \
sed "s/.LP//g" | \
sed "s/.TH //g" | \
sed "s/.SH //g" | \
sed "s/.BR //g" | \
sed "s/.RI //g" | \
sed "s/.BI //g" | \
sed "s/.RI \[\\\| \\\//g" | \
sed "s/.I \\\//g" | \
sed "s/.br/\n/g" | \
sed "s/fI//g"
}
view_me4 () {
if [ ! $1 = "Select" ]; then
manfile2view=$(find /usr -name ${1}.1*)
if [ $(echo ${manfile2view##*.}) = "gz" ]; then
zcat $manfile2view | macro_4 > /tmp/gtkman
else
cat $manfile2view | macro_4 > /tmp/gtkman
fi
fi
}
' > /tmp/ashfunc
export MAIN_DIALOG='
<wtitle>gtkman</wtitle>
<vbox>
<hbox>
<button>
<label>Quit</label>
<input file>exit.png</input>
</button>
</hbox>
<combobox>
<variable>MAN_LIST</variable>
'${COMBOLIST}'
<action>view_me'${VIEW_ME}' ${MAN_LIST}</action>
<action>clear:EDIT</action>
<action>refresh:EDIT</action>
</combobox>
<frame manpage view>
<edit>
<width>500</width>
<height>300</height>
<input file>/tmp/gtkman</input>
<variable>EDIT</variable>
</edit>
</frame>
</vbox>
'
gtkdialog1 --center --wmclass gtkman --program=MAIN_DIALOG -i /tmp/ashfunc
#clean up
rm -f /tmp/gtkman
rm -f /tmp/ashfunc
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Nice, we have needed a decent manpage viewer for a while.
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.
the patch is here:
http://www.murga-linux.com/puppy/viewto ... 164#631164
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.
the patch is here:
http://www.murga-linux.com/puppy/viewto ... 164#631164
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].
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
Another small tools for mentioned above purposes:
Rman - standalone man page converter (converts man to html or plain text)
asm-toys - multicall tool, includes simple cdplayer
asmutils - coreutils,util-linux, netutils, shell and some other tools including cda2raw
Rman - standalone man page converter (converts man to html or plain text)
asm-toys - multicall tool, includes simple cdplayer
asmutils - coreutils,util-linux, netutils, shell and some other tools including cda2raw
- Attachments
-
- asm-toys-0.2.1.tar.gz
- (80.17 KiB) Downloaded 498 times
-
- rman_3.2.tar.gz
- (77.54 KiB) Downloaded 461 times
SUUM CUIQUE.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I've been working with musl ind tinyx11 to see what I could build. It looks pretty promising so far. These are the uncompressed sizes:
jwm579 with xpm,png & jpg -448kb (earlier versions may be smaller?)
(Edit: jwm is only 274kb without png/jpg - only xpm)
desklaunch-104kb
rxvt-157kb
meh-270kb
9menu-94kb
mupdf-1182kb
wmix-138kb
calctool-124kb
pupslock-127kb
how does that compare with the uclibc toolchain?
jwm579 with xpm,png & jpg -448kb (earlier versions may be smaller?)
(Edit: jwm is only 274kb without png/jpg - only xpm)
desklaunch-104kb
rxvt-157kb
meh-270kb
9menu-94kb
mupdf-1182kb
wmix-138kb
calctool-124kb
pupslock-127kb
how does that compare with the uclibc toolchain?
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: 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 examples
technosaurus: 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:
so your builds looks very promising! The size might depend on how much your tinyX is modified - above is build with a tinyX that I also use to build the gtk-apps with.
From amigos repo a file manager with drag&drop: uxplor.
It also work with older kernels where ROX and emelfm tends to fail.
technosaurus: 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:
Code: Select all
-rwxr-xr-x 1 root root 101596 2012-06-05 10:36 9menu*
-rwxr-xr-x 1 root root 140052 2012-06-05 10:36 calctool*
-rwxr-xr-x 1 root root 126960 2012-06-05 10:36 desklaunch*
-rwxr-xr-x 1 root root 437644 2012-06-05 10:36 jwm*
-rwxr-xr-x 1 root root 261600 2012-06-05 10:36 meh*
-rwxr-xr-x 1 root root 136688 2012-06-05 10:36 pupslock*
-rwxr-xr-x 1 root root 187532 2012-06-05 10:36 rxvt*
-rwxr-xr-x 1 root root 180808 2012-06-05 10:36 wmix*
From amigos repo a file manager with drag&drop: uxplor.
It also work with older kernels where ROX and emelfm tends to fail.
- Attachments
-
- snap0003.png
- (26.86 KiB) Downloaded 965 times
I've dug up the nroff patch. Not bothering to attach the original, since it's hopelessly ancient...
And yes, it does have bad formatting.
And yes, it does have bad formatting.
- Attachments
-
- bb-nro.bz2
- Busybox nroff patch updated for Busybox 1.18.4 (not tested with 1.2x)--BAD FORMATTING!
- (1.19 KiB) Downloaded 453 times
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
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.goingnuts wrote:PANZERKOPFas most assembler progs for linux I have seen are a factor 5-10 smaller than the normal
Also, If you like assembler, play with KolibriOS. Really cool
SUUM CUIQUE.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
assuming the coders are equally competent ...PANZERKOPF wrote: Assembler progs are always faster and smaller than same written in other language.
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 fine
Last edited by technosaurus on Fri 08 Jun 2012, 04:45, edited 1 time in total.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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 [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
If apps are trying g++, that's because they look for a C++ compiler.technosaurus wrote: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
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.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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)Ibidem wrote: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.
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 [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].