Puppy In-House Development

[Iguleder]

I'm aware of that, but I want it to be clean. I want the whole thing to work without additional parameters, so EFISTUB can be used in the future.

[technosaurus]

When I did microsaurus, one of the things that really helped to simplify things was making every executable path a symlink to /bin and every library path a symlink to /lib (and similar things with other common areas: modules, images, xdgdirs...) The kernel with builtin initramfs (static Xvesa, jwm, rxvt and busybox) was less than 1Mb. This worked better than I could have expected for speeding up start times when the prime purpose was size reduction. It turns out that a lot of the time goes to looking in directories for executables and libraries, and even kernel module loads were nearly instant with everything in /lib/modules/<version> rather than in subdirs (though certain programs need to be patched to remove those hardcoded paths - ndiswrapper.c is one example)

[Iguleder]

Currently, the file system is very simple - only /bin and /lib, only static libraries.

Since things fail to build against tinyxlib, I'm currently improving it so it gets installed as libX11.a, while other libraries are links to it. This solves unresolved symbol problems which arise when applications assume they need to link only against a single library, without its dependencies.

EDIT: it's awesome! JWM recognizes all available extensions and X libraries now.

EDIT 2: other applications are still messed up because of static linking. Now I understand why pupngo has shared libraries

[technosaurus]

How are they "messed up by static linking"? I've never had that problem. Is it possible that hardcoded compiled builtin paths need to be fixed? If you build with a standard Puppy, then it will try to put stuff in /usr/... due to $PREFIX env var and many others... for autotools, you need to specify --prefix=, --bindir=, --sysconfdir=, --localstatedir=, etc... and rox requires some xdg dirs to be set.

[goingnuts]

..Now I understand why pupngo has shared libraries

you mean no libraries If not you are studying quite old version...
Next step might be to do multi-call binaries of jwm, xfbdev, init, rxvt...

[Iguleder]

How are they "messed up by static linking"?

When an application wants to link against libXt, it assumes libXt is linked against its own dependencies. That's true for shared objects, but not for static libraries - when something links against it statically, you get hundreds of undefined functions.

EDIT: using pkg-config and passing "--static" through a wrapper in $PATH seems to solve all X11 linking problems.

EDIT 2: lookin' good! Still fighting glib and GTK1, but I got JWM to build with Xft support.

Code: Select all

#!/bin/sh
for i in linux_headers musl lazy_utils loksh tinyxlib xinit zlib tinyxserver font_cursor_misc font_misc_misc font_alias freetype expat fontconfig libxft jwm ttf_bitstream_vera; do sh build.sh $i; done
. ./config
cd $SYSROOT/usr/share/fonts/misc
mkfontscale
mkfontdir

[goingnuts]

...EDIT 2: lookin' good! Still fighting glib and GTK1, but I got JWM to build with Xft support.

You might want to use attached patches.

[Iguleder]

Got GTK1 to build.

Here's what I get when I run emelFM:

GLib-ERROR **: could not allocate 4294967295 bytes
aborting...

[Ibidem]

Got GTK1 to build.

Here's what I get when I run emelFM:

GLib-ERROR **: could not allocate 4294967295 bytes
aborting...

That looks like UINT_MAX/WEOF/WCHAR_MAX (0xFFFFFFFF), but I have no idea where it comes from.

[technosaurus]

I had that issue once when building gtk1 with musl, but it fixed itself after rerunning configure with a couple of -D*** CFLAGS (I don't recall if it was POSIX, GNU or some other _SOURCE option) ...for musl make sure you enable large file support. Both gtk and glib 1 need a LOT of code cleanup. I started on some of it, but only got about half way through glib (if you can simply ignore the bloat, it would probably only take an hour or so)

[Ibidem]

Ah yes. musl always has large file support (no 32-bit off_t), so some things do get rather picky...I would not be surprised if that was the issue.

_ALL_SOURCE is supposedly default now, but I'm inclined to pass -D_XOPEN_SOURCE=600 -D_BSD_SOURCE
(just because of some of the GNU braindamage). With musl, -D_XOPEN_SOURCE=700 gives you POSIX2008/POSIX2013, but -D_XOPEN_SOURCE=<number less than 700> gives you that plus the functions that were removed before then.

-D_LARGEFILE64_SOURCE makes musl look like glibc exposing off64_t and related ABI.

[technosaurus]

Here is a useful script helper for sorting:

Code: Select all

#include <stdlib.h>
#include <string.h>
static inline int cmp(const void *a, const void *b){
   return strcmp(*(const char **)a, *(const char **)b);
}

int main(int argc, char *argv[]){
    qsort(++argv, --argc, sizeof(char *), cmp);
    while (argc){
      write(1,argv[0],strlen(argv[0]));
      write(1,(--argc && argv++)?"\t":"\n",1);
   }
}

it could be extended to use strcasecmp, strverscmp

[Iguleder]

On my way home, I'll try to rebuild glib. I hope it's going to work, since I have only two days to work on it.

Next week I'll be busy with my new apartment, so I won't have much time to mess with this project.

EDIT: I found out that g_malloc() receives a gulong (which is 32-bit), while stat() returns a 64-bit off_t, which gets truncated to ULONG_MAX. I'm currently trying to rebuild GLib and GTK1 with gulong as unsigned int, to see whether the problem is gone.

EDIT 2: the problem persists. I ran GDB and I think the problem is here:

Code: Select all

guint bufsize = sysconf (_SC_GETPW_R_SIZE_MAX);

GLib allocates this size, but musl's sysconf() returns -1, (signed) which is put in a gulong (unsigned). I'm rebuilding GLib with a fixed buffer size I took from glibc's headers - this looks more promising

EDIT 3: yay!

[Iguleder]

More good news - I got emelFM and Beaver to cross-compile cleanly, without any modifications, using wrappers for glib-config and gtk-config.

Any recommendations for more GTK1 applications? Currently, ROX-Filer and mtPaint are the TODO list.

[greengeek]

Maybe a basic audio recording program? (Is there a GTK1 version of something like mhwaveedit??). And a basic audio player.

[goingnuts]

abiword gtkedit aumix guiTAR gwhere sylpheed xchat danpei ProView grip blinky chbg dillo easytag gcombust gcrontab gdmap gftp gimp gksu gnumeric gtkdiff gtkdiskfree gtkfontsel gtk-iptables gtk-parted LinNeighborhood LinPopUp MPlayer seamonkey uxplor Xdialog gtkdialog xhippo

[Iguleder]

mtPaint joined the family

EDIT: X-Chat too!

EDIT 2: GdMap too!

[wjaguar]

the problem persists. I ran GDB and I think the problem is here:

Code: Select all

guint bufsize = sysconf (_SC_GETPW_R_SIZE_MAX);

GLib allocates this size, but musl's sysconf() returns -1, (signed) which is put in a gulong (unsigned). I'm rebuilding GLib with a fixed buffer size I took from glibc's headers - this looks more promising

In GTK+2 that part was done properly:

Code: Select all

glong bufsize = sysconf (_SC_GETPW_R_SIZE_MAX);
if (bufsize < 0) bufsize = 64;

GTK+1 needs the same.

[Iguleder]

Wow, a comment from mtPaint's developer!

I had to define NEED_CMYK for mtPaint to build - it seems the PNG code needs it, too - I believe it should be removed.

[Ibidem]

Maybe a basic audio recording program? (Is there a GTK1 version of something like mhwaveedit??). And a basic audio player.

Last I knew mhwaveedit still supported GTK1...
Yup,

Code: Select all

--disable-gtk2          Don't use GTK+ 2, use 1.2 instead

In 1.4.23 (released August 11 this year).


For an audio player I recommend the old standby: xmms (1.2.11).
OTOH, it may be hard to get it working statically--haven't tried, but I know it relies on plugins.

Other programs:
gato (gtk1 "at" interface)
geg (graphing calculator)
manedit (a gui for writing manpages)
gtkpool (gtk1 billiards game)
gps (gtk1 "ps" interface/odd task manager, not a GPS program)
paul, danpei, gtksee (image viewers)
gpppon

That's what I can remember, but...I know there were a lot more.
Ah yes, gtkboard, and wallp.