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 19 Oct 2017, 00:03
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
xwoaf - rebuild
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 3 [43 Posts]   Goto page: Previous 1, 2, 3
Author Message
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Wed 21 Dec 2016, 17:32    Post subject:  

Thank you for testing - very nice feedback!
I did have a quick test of xaw3dxft - tested linking with chimera - works OK.
I will try to make a build package with my xawplus variant of xwoaf.
Back to top
View user's profile Send private message Visit poster's website 
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Wed 21 Dec 2016, 17:41    Post subject:  

foxpup wrote:
Thanks Keef!

Works very well. xwaof boots very fast on my P3 (amd palomino). It's faster than anything Smile

I put it on ext3, next to several frugal puppies. So it does not have to be ext2.

However 2 issues for now:
my keyboard is azerty (be-latin1)
I have no internet, normally it is a network connection, ethernet, eth0

How can I set up these?
Where can I find this kind of info, or even what is or is not possible?

For keyboard you will have to modify the build - and for ethernet you need to build the kernel and correct module for your net device - and then rebuild the image. A lot of work without guarantee for success - but also a lot of fun while doing it Cool
Back to top
View user's profile Send private message Visit poster's website 
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Tue 24 Jan 2017, 14:59    Post subject:  

It bothered me to release xwoaf-toolchain without the ability to rebuild the old kernel-2.2.25. It needs gcc-2.95.3 or older - every test to patch kernel source to accept gcc-3.x.x have failed. And cross compiling gcc-2.95.3 to work in the toolchain also failed. But:
One can build a simple gcc-2.95.3 within the toolchain using gcc-3.4.3, install it in /opt and then use it to compile the kernel. Only minor patch to the kernel needed to cope with binutils-2.19.1.

It is important to link cc to the gcc-2.95.3 compiler before doing the kernel build - it is linked to ccache in the toolchain.
Ran into problems with missing as86 and ld86 - not every version of it builds with uclibc to a working bin - but bin86-0.4 does.

So in the end I am now able to compile the original xwoaf kernel-2.2.25 and modules to same size and features as the original.

I have updated the howto here where also xwoaf-build-package_kernel.tar.gz can be downloaded (buildscripts, patches and sources).
So the adventurous can now time travel back and build kernel 2.2.25 (bl3, xwoaf and skatos are some of the more known distributions that used it or nearby relatives).
Back to top
View user's profile Send private message Visit poster's website 
NeroVance


Joined: 10 Oct 2012
Posts: 193
Location: Halifax, Canada

PostPosted: Sat 11 Feb 2017, 15:16    Post subject:  

BarryK wrote:
Yes, I see so many interesting projects, that have been forgot or lost, bits and pieces that could be put together to build a new kind of radically small, lean-and-mean Puppy.

A new pup built with xlib apps, tinyx, and gtk 1.2, would be great. There were such nice gtk1.2 apps that we abandoned. Also there were some very interesting projects, such as xft support in gtk1.2, for antialiased fonts -- there was a git site for that.


Tbh I would love to see what software can still be compiled with gtk1.2 and if there are older versions of some software of which we cannot compile that would still suit our needs.

I feel like Puppy has really changed a lot since even the 4.x days. From the loss of Tcl, to the splintering into dozens of different puppies. I like the variety, but at the same time, it seems like it adds a lot of possible incompatibility, back in the day you didn't have to worry about what the base distro was and what arch the package needed to be in Confused

If you wanted a program you would just hit up the forum and people would show their wares, almost like a little informal marketplace, which I will admit I always liked Very Happy
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Wed 15 Mar 2017, 17:35    Post subject:  

NeroVance: Agree! One option to address the possible incompatibility of pets for various versions of Puppy could be to supply static linked binaries. This give "portability" beyond Puppy as well. I know this is not possible with some applications, but when possible, it could be the target. Size on disc will increase but that is really not a limiting factor for most users...

Some findings working further with xwoaf...

My first approach to get more room was to use "mklibs" which repack the dynamic libraries to only contain what the applications on the floppy needs - and that does work.

Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).

sstrip reduces a tiny bit but not with the magnitude I was looking for.

exepak works - but upx seems more efficient.

The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.

upx can compress the kernel but afterwards kernel wont boot.

Never compress busybox as execution speed decreases a lot.

My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.

The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.

The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.

At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.


xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4745

PostPosted: Thu 16 Mar 2017, 17:25    Post subject:  

goingnuts wrote:
...
Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).

sstrip reduces a tiny bit but not with the magnitude I was looking for.

exepak works - but upx seems more efficient.

The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.

upx can compress the kernel but afterwards kernel wont boot.

Never compress busybox as execution speed decreases a lot.

My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.

The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.

The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.

At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.


xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image

I came to the same conclusions regarding upx on a compressed squashfs as well as inside an initramfs contained within a compressed kernel.

I'd be willing to start/contribute-to a github project for a basic X-app mcb. Xvesa/fbdev + jwm + a terminal(st?). I could even make it work as a submodule of toybox if thats what people prefer. I have the start of a basic C library that could be incorporated into the project so that the C library is not an issue. I also have a patch for jwm that significantly reduces RAM usage (uses nanosvg and stb-image instead of cairo, jpeg and png ... also adds support for gif, bmp, photoshop and other images) With black background running Xvesa, jwm and rxvt, I had it under 4Mb (~3.7Mb IIRC). The background actually used more resources than all 3 of those apps combined with my screen resolution (4MB).

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

Joined: 07 Dec 2008
Posts: 891

PostPosted: Fri 17 Mar 2017, 14:26    Post subject:  

technosaurus: Thank you for the feedback. For me the mcb process is a collection of sources, patches and build scripts - if that is what you are suggesting I would like to contribute. If its a rewrite of source code - I do not think I can contribute much. I am not quite sure how licenses should be handled when creating mcbs - any thought on that subject?
There might be a synergy between a floppy distribution and a basic initramfs for larger sized distribution: Both could target GUI environment and basic system applications/tools.
I find XawPlus based applications small enough to fit in floppy size but they lack keyboard handling (as far as I can tell) - that is a major drawback if you only have keyboard to navigate with. If you or others know ways to configure Athena widgets to be controlled by keyboard only, I am very interested in a how-to-do-it.
Back to top
View user's profile Send private message Visit poster's website 
Keef


Joined: 20 Dec 2007
Posts: 864
Location: Staffordshire

PostPosted: Fri 17 Mar 2017, 15:27    Post subject:  

Don't know if this is useful. http://xawm.sourceforge.net/

Quote:
The XawM Widget set is based on the widely-distributed Xaw3d widget set. XawM makes a few changes required to give Athena the "modern" look-and-feel. It borrows a few features from neXtaw and other widgets sets as required to obtain a modern look and feel, although the actual source code is entirely based on Xaw3d.


Quote:
Of special interest is the addition of keyboard traversal. I may also add pixmap handling because some modern applications like to have color images, and because it will help encourage people to port to it.

No attempt will be made to add new functionality to the existing widget set. This library is intended to be compatible with the Athena widget set.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Fri 17 Mar 2017, 17:10    Post subject:  

Thanks Keef! It should add the keyboard navigation - the functions are there. A first try did not work - but you gave me something to follow.
Update: It actually works - sort of: Navigation with Tab and activation with Spacebar is OK but mouse clicks are ignored - despite setting focusPolicy in .Xdefaults. Another issue is lack of focus when application starts - focus seems to be set by mouse pointer...
Back to top
View user's profile Send private message Visit poster's website 
goingnuts

Joined: 07 Dec 2008
Posts: 891

PostPosted: Mon 27 Mar 2017, 15:11    Post subject:  

Attached a patch to jwm-0.23 which add features from later versions:
* scale icons in menu
* do not show sticky windows in pager
* shade/unshade window with mouse button 4 & 5
* change desktop with with mouse button 4 & 5
* restack windows
* move/resize windows with Alt+mouse button 1 & 3
* adds -restart function

without major increase in size of compiled binary.

Motivation was to get desklaunch running in xwoaf - it needs the ability to move generated (sticky) icons with Alt+mouse button 1. Random number of icons was drawn when running desklaunch - the restack helped on that. And all icons showed up in pager - not pretty Rolling Eyes .

My xlibs multicall binary has been expanded with desklaunch so now holds static linked bins of: desklaunch-1.1.7 jwm-0.23 menu-3.00 rxvt-2.6.4 xcmd-1.05 xinit-1.0.1 and xsetroot-1.5.
The mcb is 133K.
Attached also image of xwoaf-version running with the above.
snap0004.png
 Description   
 Filesize   55.93 KB
 Viewed   268 Time(s)

snap0004.png

jwm-0.23_various.diff.gz
Description  fake gz-extension
gz

 Download 
Filename  jwm-0.23_various.diff.gz 
Filesize  10.25 KB 
Downloaded  33 Time(s) 
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8280
Location: Perth, Western Australia

PostPosted: Sat 08 Apr 2017, 21:05    Post subject:  

I have created chrootable MUSL filesystems from Alpine Linux packages, for x86_64, x86 and armhf, see my blog post:
http://barryk.org/news/?viewDetailed=00524

Now, the temptation to use the x86 MUSL rootfs in xwoaf, became overwhelming. So, gave it a go.

Download the x86 rootfs from here (67MB):
http://distro.ibiblio.org/quirky/alpine/x86/developer/alpine-rootfs-x86.tar.gz

It expands to folder 'alpine-rootfs-x86'.
Copy script 'chroot-x86' out of it, and use that instead of xwoaf's 'xwoaf-dev.sh' to chroot into alpine-rootfs-x86.

Expand 'xwoaf-build-package.tar.gz' inside alpine-rootfs-x86, then "cd src". Instead of running "./xwoaf_build", I did "cd recipes" and ran "./tinyxlib-0.01.sh"

...success!!!

However, the next one, "./tinyxserver-0.03.sh" has hit a hurdle:
Code:
kmap.c:38:22: fatal error: asm/mtrr.h: No such file or directory
 #include <asm/mtrr.h>


...now what?

EDIT:
Ah, asm/mtrr.h is in the linux-headers package. As the Alpine rootfs has the 'apk' package manager installed, and has Internet access from within the chroot, I *should" be able to install that.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8280
Location: Perth, Western Australia

PostPosted: Sat 08 Apr 2017, 21:37    Post subject:  

Continuing from previous post. Having chrooted into 'alpine-rootfs-x86', if there is Internet access, then /etc/resolve.conf also got copied in, so have Internet access inside the rootfs.

So, did this:
Code:
puppypc21513:/src/recipe# apk add linux-headers
(1/1) Installing linux-headers (4.4.6-r1)
OK: 196 MiB in 74 packages


Of course, xwoaf is using an older kernel. Never mind that for now.

compiling tinyxserver now gets to:
Code:
/usr/bin/gcc  -DNOERROR -Wl,--gc-sections,--sort-common,-s -o Xfbdev dix/libdix.a os/libos.a hw/kdrive/fbdev/libfbdev.a miext/layer/liblayer.a hw/kdrive/libkdrive.a hw/kdrive/linux/liblinux.a miext/shadow/libshadow.a fb/libfb.a mi/libmi.a Xext/libext.a Xext/extmod/libextmod.a XTrap/libxtrap.a randr/librandr.a render/librender.a record/librecord.a -L/usr/lib /usr/lib/libXfont.a  -lXext -lX11 -lXdmcp -lz -lm
/usr/lib/gcc/i586-alpine-linux-musl/6.2.1/../../../../i586-alpine-linux-musl/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
make: *** [Makefile:33: Xfbdev] Error 1


EDIT:
Ah ha, zlib dev files are missing, so did this:
Code:
puppypc21513:/src/recipe# apk add zlib-dev
(1/1) Installing zlib-dev (1.2.8-r2)
OK: 196 MiB in 75 packages


Ha ha, not there yet:
Code:
make[1]: Entering directory '/src/build/tinyxserver-0.03/hw/kdrive/vesa'
/usr/bin/gcc -I../../../include -I../../../mi -I../../../miext/layer -I../../../fb -I../../../render -I../.. -pipe -fPIC -Os -Wall -D_BSD_SOURCE -D_GNU_SOURCE -D__KERNEL_STRICT_NAMES -fno-strength-reduce -nodefaultlibs -fno-strict-aliasing -ffunction-sections -fdata-sections -I. -I/usr/include -DNOERROR -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DTOSHIBA_SMM -D_SVID_SOURCE -D_GNU_SOURCE -DX_LOCALE -DKDRIVESERVER -DGCCUSESGAS -DDDXOSINIT -DNOFONTSERVERACCESS    -DNDEBUG -DNARROWPROTO -DPIXPRIV  -DFUNCPROTO=15 -DCOMPILEDDEFAULTFONTPATH=\"/usr/X11R6/lib/X11/fonts/misc/\" -DRGB_DB=\"/usr/X11R6/lib/X11/rgb\" -D_POSIX_C_SOURCE=2                    -DUSE_RGB_TXT     -D__KERNEL_STRICT_NAMES    -c -o vga.o vga.c
In file included from vesa.h:29:0,
                 from vga.c:25:
vm86.h:54:22: fatal error: sys/vm86.h: No such file or directory
 #include <sys/vm86.h>


Fascinating hey! I have to leave it for now, have other things to do today.

EDIT2:
A quick note before I depart though. the 'linux-headers' that I installed has /usr/include/asm/vm86.h.

goingnuts,
What do you reckon, would that asm/vm86.h be ok?

Of course, this is kernel 4.4.x. But, I am interested in compiling xwoaf with recent kernel, not concerned about that fitting-in-a-floppy requirement.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8280
Location: Perth, Western Australia

PostPosted: Sun 09 Apr 2017, 05:54    Post subject:  

goingnuts sent me a pm, to work that iguleder and ibidem did with tinysxerver and musl:
http://murga-linux.com/puppy/posting.php?t=51478&mode=topicreview&postorder=DESC&start=150&sid=27a2c49e13394080ab1455fbae980a7c

...had a brief glance, see mention of that asm/vm86.h

Anyway, I have scratched this particular itch. My Alpine rootfs could be used for the xwoaf build, but will need more work.
Also, it will need the proper kernel headers for the kernel that xwoaf is using.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 3 of 3 [43 Posts]   Goto page: Previous 1, 2, 3
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
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.1272s ][ Queries: 14 (0.0145s) ][ GZIP on ]