Puppy In-House Development

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

[amigo]

See here:
http://distro.ibiblio.org/amigolinux/do ... lications/
for loads of gtk1 stuff. Sources and build scripts are all there.

[Iguleder]

Here's a teaser

[mistfire]

I know that you want to make the puppy linux smaller. I noticed that there is a heavy fragmentation on application development for puppy. Some apps were build from C,C++,Shell Script, GTK+, python, vala, genie, bacon, etc. Is it possible to build default applications for puppy using only one programming language in order to remove some runtime libraries for other programming languages and make it as optional package or put it devx_sfs.

We must standardize the puppy linux development. we must select one programming languages and toolkit as default development tool for puppy to make it developer friendly.

[Iguleder]

That's one of the reasons I'm doing this

I want to build a SDK from all these packages, which can be used to write applications that work in any Puppy (thanks to static linking).

[wjaguar]

I had to define NEED_CMYK for mtPaint to build - it seems the PNG code needs it, too

Thanks, fix will be in the next version. It is PAM code (which is builtin) that needs CMYK support, which only JPEG and TIFF (both optional) needed before.