Fifth: A New Web Browser Based On WebKitFLTK

[Ibidem]

On Alpine Linux, many libraries don't have static versions available (icu and harfbuzz being the relevent ones), so linking fails. Any ideas for how to do this? (libwebkitfltk.so ? Add dependencies to the pkg-config entry that's planned?)
Removing the -Wl,-Bstatic I get a libwebkitfltk.a that's 309389762 bytes.

Also, running autoconf in fifth doesn't make a working configure script; I'll try the tarball.

[curaga]

Testapp linking those statically was just a preference (I needed to see how big a binary it would create, as the portable binary needs those statically), it's now been removed.

Do you need a shared libwebkitfltk? It should work by adding -fPIC to your CXXFLAGS, but I haven't tested it, as the total space use on a system would be much more when only one app uses it.

On autoconf, most packages don't use autoconf directly, they use autoreconf in their autogen.sh scripts. Try autoreconf -i.

[ssokolow]

that libc is broken, not different. different would provide same apis with different implementations.

It's using musl which is a lot less broken than glibc and does provide the same APIs... just not perfect ABI compatibility yet.

(The lead musl developer is the guy who "bashed" systemd because he has ridiculously high standards for core system components. That should put that chart I linked into context.)

An LSB-compatible ABI is on their TODO list, which should be the part you need for drop-in compatibility, but it's listed as incomplete because they're focusing first on making musl superior in places like embedded systems where ?Clibc and dietlibc have proved that you don't need perfect drop-in ABI compatibility to be useful.

[curaga]

0.1.1 tarballs released, with build fixes for musl, some glibc versions, and other tweaks.

[Ibidem]

0.1.1 tarballs released, with build fixes for musl, some glibc versions, and other tweaks.

Have been rebuilding for about 4 hours now (Atom N270, so I expect it to be slow; the 1 gigabyte of ram is small enough that -j2 would cause swap thrashing, and both ram and hard drive are slow...).
Is there a Makefile that builds all the way through, instead of make -C ... && make -C ... && ...?
I presume that the test app should run not segfault; I'll need much more space free for a debug build, though.
Fifth was also segfaulting (in the dynamic linker, according to gdb).

[cb88]

Have been rebuilding for about 4 hours now (Atom N270, so I expect it to be slow; the 1 gigabyte of ram is small enough that -j2 would cause swap thrashing, and both ram and hard drive are slow...).
Is there a Makefile that builds all the way through, instead of make -C ... && make -C ... && ...?
I presume that the test app should run not segfault; I'll need much more space free for a debug build, though.
Fifth was also segfaulting (in the dynamic linker, according to gdb).

Perhaps you could try using the ninja make engine.... its alot faster and is what is used on Haiku OS for building webkit there... due to the increased build speed (cuts development time considerably apparently)

[curaga]

Is there a Makefile that builds all the way through, instead of make -C ... && make -C ... && ...?

Not ATM, trying to avoid merge conflicts where possible (plus each is somewhat a separate whole with different dependencies).

I presume that the test app should run not segfault; I'll need much more space free for a debug build, though.
Fifth was also segfaulting (in the dynamic linker, according to gdb).

Yeah, no use trying fifth until the minimal testapp works. I don't have the space for a full -g build either, so I usually rebuild just the specific files with -g.

[curaga]

@Ibidem

There's another checkpoint of sorts - does the jsc executable run? It's a smaller test than the testapp, being only WTF + JavascriptCore.

In other news, Dillo hg has a proper fix for the focus thing.

[Ibidem]

@Ibidem

There's another checkpoint of sorts - does the jsc executable run? It's a smaller test than the testapp, being only WTF + JavascriptCore.

Should probably poke at that...I know that there were thread stack size issues for jsc in other webkit versions.
It looks like the issue I was hitting is PIE.

Got it. The line number in your original report seems to be off by a
bit (it points to TLSDESC related cases) but I've found the offending
relocation(s):

0083deea 0000c402 R_386_PC32 00000000 exp
0083df03 00010a02 R_386_PC32 00000000 log
0083df1c 00030502 R_386_PC32 00000000 floor
0083df35 00024502 R_386_PC32 00000000 ceil

I have no idea why the linker is emitting these. It should have
resolved them at ld time to PLT entries in the main program's PLT, but
maybe since you're building as PIE (this is defautl on Alpine) that
doesn't happen (this would be a linker bug, IMO). If it were going
to do this (leave the relocations in the output), it should mark the
program as DT_TEXTREL (having textrels), but this is probably
suppressed for PIE because it's not supposed to happen.

My best guess as to what's triggering the problem is that there's some
nasty asm or other hacks that are not PIE-compatible somewhere in the
program. It's also possible that you're pulling in static libraries
(which would not be PIE-compatible) due to not having the dynamic
version of a needed library installed.

Finding which .o or .a file these references to exp/log/floor/ceil are
coming from would help narrow down the source of the problem.
Alternatively you could try building as non-PIE.

I guess that means a little bit of tweaking for the C*FLAGS; I need to read up on PIE/PIC/...
Would it be likely to work if I build the same way but with -fPIC (and the -static-...stuff gone)?

In other news, Dillo hg has a proper fix for the focus thing.

I saw that last night; alpine now has FLTK 1.3.3 and a patched dillo.

I've packaged physfs; urlmatch still needs packaging, but builds fine.

A minor rough spot I ran into with the Fifth configure script earlier: the version test uses <webkit.h>, so to install in /opt/wkf/ you need something like

CXXFLAGS="-I/opt/wkf/include -I/opt/wfk/include/webkitfltk -L/opt/wkf/lib

.
If there were an option like --with-webkitfltk=..., it would be a nice aesthetic touch.

[Bm33on]

There are bound to be like-minded people that want a browser like this.