OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => OpenBSD => Topic started by: ins0mniaque on October 04, 2005, 04:24:54 pm
-
I'm been trying to build a graphical web browser, but it seems that they are all not ported to the "arm" processor. mozilla, firefox and minimo are not "ported" and koqueror-embedded is horrible. Even w3m doesn't compile (will try to fix it if I have time, or I'll test again in 1-2 weeks and correctly report it to the ports team), ok, it's not graphical, but at least it's a text browser I'm used to use.
What are you guys using? I would be really happy to have access to maps.google.com (It should work in Minimo IIRC)
-
I'm been trying to build a graphical web browser, but it seems that they are all not ported to the "arm" processor. mozilla, firefox and minimo are not "ported" and koqueror-embedded is horrible. Even w3m doesn't compile (will try to fix it if I have time, or I'll test again in 1-2 weeks and correctly report it to the ports team), ok, it's not graphical, but at least it's a text browser I'm used to use.
What are you guys using? I would be really happy to have access to maps.google.com (It should work in Minimo IIRC)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=98176\"][{POST_SNAPBACK}][/a][/div]
Dillo worked fine for me, but I really didn't use it much.
Good luck!
-
But IIRC, Dillo does not display maps.google.com at all.
-
This is a real problem... I'm going to see if I can figure out why Firefox won't compile on this platform (it fails if you remove the mask from the Makefile - it isn't just 'that simple').
I really, really, really want a browser that can handle JavaScript well so that the moinmoin GUI based editor works.
- Andy
-
Good day!
<SNIP>
What are you guys using? I would be really happy to have access to maps.google.com :) (It should work in Minimo IIRC)
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=98176\")
I use elinks and lynx(with qiv for images) heavily, minimo[0] sometimes.
Mabuhay! barryg
[a href=\"ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/arm/minimo-20050802p2.tgz]ftp://ftp.openbsd.org/pub/OpenBSD/snapsho...-20050802p2.tgz[/url]
http://www.openbsd.org/cgi-bin/cvsweb/ports/www/minimo/ (http://www.openbsd.org/cgi-bin/cvsweb/ports/www/minimo/)
--
Barry Dexter A. Gonzaga
-
OK, I managed to tweak the build to start Firefox 1.5.01 building on the Zaurus. It's going to take a while to build though and then I probably want to build epiphany (dependent on Mozilla's Gecko engine) to reduce the overhead a little but I will keep you posted when I have some positive results.
- Andy
-
Damn, 19 hours later it segfaulted... I may have mistuned nspr.... ah well in the meantime I have been looking at memory usage.
OpenBSD binaries on arm seem to have about the same memory utilisation as the i386 ones and Firefox built with gtk-2 runs at about 46Mb
I'm now building Epiphany after tuning nspr on the mozilla dev stuff. If it works and looks nice I will probably build again if it is too big using gtk-1 and see how thing progress.
I will provide a build tweaking transcript (and maybe some ports patches) if it works ok.
- Andy
-
Hi. Firefox is working fine on pdaxrom. Perhaps they can help you.
I say it is fine. I should admit that it is great but only once it has started. It does take some time to load.
Good luck.
-
Thanks Macwiz, I have used Firefox quite a bit on PDAXROM and I think they build against GTK1, however, the build is slightly different since the nspr framework is OS aware and chooses some different options when running on OpenBSD.
- Andy
-
You could also look how we handled Firefox in OpenEmbedded. Other option can be gpe-mini-browser which base on GTK-Webcore (also in OpenEmbedded). Both use gtk2 because we try to avoid gtk1 at all.
Dillo is too simple to use it for sites which use lot of CSS and/or Javascript.
BTW - cannot OpenBSD use cross-compilers? Building stuff on Zaurus reminds me building kernel on Amiga with 68040/40 - 3h (when cross-compiled on pII/400 it was ~20 minutes).
-
You could also look how we handled Firefox in OpenEmbedded. Other option can be gpe-mini-browser which base on GTK-Webcore (also in OpenEmbedded). Both use gtk2 because we try to avoid gtk1 at all.
Dillo is too simple to use it for sites which use lot of CSS and/or Javascript.
BTW - cannot OpenBSD use cross-compilers? Building stuff on Zaurus reminds me building kernel on Amiga with 68040/40 - 3h (when cross-compiled on pII/400 it was ~20 minutes).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115085\"][{POST_SNAPBACK}][/a][/div]
Thanks HRW, the main reason for this is Javascript support yes.
OpenBSD can and does use cross compilers if you want to build OpenBSD alone, the whole base system can be built like that but it is recommended to use native compilation once the first iterations have been built.
The ports tree (the automated build from source system for the non distro applications... covers everything not in base OpenBSD or XOrg) on the other hand isn't enabled for cross compilation and never will be. The view they take is that it is all messy code that they don't have any control over and aren't going to spend time nailing it to work for cross compilation on all the architectures they support - and quite right too really
The upside is that in most cases the ports system works exactly like it does on any other architecture. Take a look at the ports make system some time, it is clean, uncluttered and pretty elegant. It even lets you go into a patch snapshot mode, make changes to a port, close the snapshot and then (assuming you have cvs write access) cvs the diffs back to the central ports cvs. - The complexity of this system would go 'through the roof' and it wouldn't be as maintainable if it were designed for cross compilation across all the different architectures.... these are the architectures they support...
alpha Digital Alpha-based systems
amd64 AMD64-based systems
cats StrongARM 110 Evaluation Board
hp300 Hewlett-Packard HP 9000 series 300 and 400 workstations
hppa Hewlett-Packard Precision Architecture (PA-RISC) systems
i386 Standard PC and clones based on the Intel i386 architecture and compatible processors
luna88k Omron LUNA-88K and LUNA-88K2 workstations
mac68k Motorola 680x0-based Apple Macintosh with MMU
macppc Apple New World PowerPC-based machines, from the iMac onwards
mvme68k Motorola 680x0-based VME systems
mvme88k Motorola 881x0-based VME systems
sgi SGI MIPS-based workstations
sparc Sun sun4, sun4c and sun4m class SPARC systems
sparc64 Sun UltraSPARC systems
vax Digital VAX-based systems
zaurus Sharp Zaurus C3x00 PDAs
16 in total.. remove the binary compatible ones and there are is a 12x12 matrix of cross compiler configurations to test... no thanks I wouldn't like to have to maintain that.
gpe-minibrowser does sound interesting.. I may take a look at that, thanks.
- Andy
-
Well I'm now itching to take a look at gpe-minibrowser but as the Openembedded/Openzaurus sites seem to be down at the moment I can't find a tarball for the project. I'm hoping it will build independently of a major portion of gpe.
Perhaps if anyone knows of a tarball for gpe-minibrowser source they can point me at it.
My browser requirement for moinmoin turned out to be that the browser was capable of handling javascript for an open source product called FCKEditor which enables GUI editing on web sites... it would be nice to see if gpe-minibrowser handles this.
- Andy
-
Perhaps if anyone knows of a tarball for gpe-minibrowser source they can point me at it.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=115224\")
As gpe is independant of OZ/OE you should have a look [a href=\"http://gpe.handhelds.org]http://gpe.handhelds.org[/url]
A shortcut would be http://handhelds.org/pub/projects/gpe/sour...ser-0.19.tar.gz (http://handhelds.org/pub/projects/gpe/source/gpe-mini-browser-0.19.tar.gz)
Most of the gpe dependencies are in the same directory
-
Perhaps if anyone knows of a tarball for gpe-minibrowser source they can point me at it.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=115224\")
As gpe is independant of OZ/OE you should have a look [a href=\"http://gpe.handhelds.org]http://gpe.handhelds.org[/url]
A shortcut would be http://handhelds.org/pub/projects/gpe/sour...ser-0.19.tar.gz (http://handhelds.org/pub/projects/gpe/source/gpe-mini-browser-0.19.tar.gz)
Most of the gpe dependencies are in the same directory
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115235\"][{POST_SNAPBACK}][/a][/div]
Great, thanks for the pointer at the sources directory Koen, I will take a look.
- Andy
-
Ok, I have all the stuff... gpe-minibrowser doesn't like sqlite version 3 on my desktop where I'm trying it first but I will try again.
The most interesting bit of all this is the Gtk-Webcore stuff. very nice, I have had obd-browser running (on desktop not on the Zaurus yet) and the render accuracy is pretty good.
However, the licensing of the Webcore is on unusual territory being owned by Nokia (check the NRC* License files). Can you ever therefore distribure the webcore libraries on their own or is this and gpe-minibrowser only for people who build from source?
- Andy
-
However, the licensing of the Webcore is on unusual territory being owned by Nokia (check the NRC* License files). Can you ever therefore distribure the webcore libraries on their own or is this and gpe-minibrowser only for people who build from source?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115252\"][{POST_SNAPBACK}][/a][/div]
gtk+Webcore is just a port from webcore (apple) which is based on khtml (kde), the only shaky part is osb-nrcit:
koen@dominion:/data/build/oe/monotone/org.openembedded.dev/packages/gtk-webcore$ grep -rn LICENSE *.bb
osb-browser_0.5.0.bb:1:LICENSE = "GPL"
osb-browser_20050430.bb:3:LICENSE = "GPL"
osb-browser_20060212.bb:3:LICENSE = "GPL"
osb-jscore_0.5.0.bb:1:LICENSE = "GPL"
osb-jscore_20050430.bb:3:LICENSE = "GPL"
osb-jscore_20060212.bb:3:LICENSE = "GPL"
osb-nrcit_0.5.0.bb:2:LICENSE = "nokia"
osb-nrcit_20050430.bb:3:LICENSE = "nokia"
osb-nrcit_20060212.bb:3:LICENSE = "nokia"
osb-nrcore_0.5.0.bb:1:LICENSE = "GPL"
osb-nrcore_20050430.bb:3:LICENSE = "GPL"
osb-nrcore_20060212.bb:3:LICENSE = "GPL"
But both the author of webcore and the author of gpe-mini-browser (both nokia employees) as well as nokia itself know that Familiar and OpenZaurus ship binaries and are pretty happy with it.
-
OK Koen, nice little browser that, actually the browser here is mostly a wrapper for that great gtk-webcore project but still it does the business and is small.
One thing though.. the browser identifies itself as Netscape (try http://www.quirksmode.org/js/detect.html) (http://www.quirksmode.org/js/detect.html)), since it is based upon Apple Webcore would it not be more sensible to make it report 'Safari' ? - it may stand a better chance of working with some of the more challenging sites.. better still being able to configure that would be great. - I suppose that's a question for the NRCore folk.
Anyway, I think I may build all that stuff for the OpenBSD on the Zaurus and see how it work on the target environment.
I have to say I was a little disappointed that the Atlantis browser wasn't open source, it looked like a more fully fledged browser (still small) but based on gtk-webcore. - license Freeware.. pah!
- Andy
-
*sigh* autogen is using some new funky Gnuism with find... regex isn't common to UNIX find commands it seems... I think I need to implement a gfind command and maybe some other stuff
-
*sigh* autogen is using some new funky Gnuism with find... regex isn't common to UNIX find commands it seems... I think I need to implement a gfind command and maybe some other stuff
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115273\"][{POST_SNAPBACK}][/a][/div]
Man that's SPOOKY.
I thought I was going to have to implement a gfind based on the gnu source... however, just found a ports package of findutils for the gnu stuff and all the commands are prefixed g.... so gfind is in it along with gxargs etc...
ah well, that saves some time
- Andy
-
aaargh, JavaScriptCore uses some non posix pthread extension pthread_attr_get_np it's not going to work without major hacking.
- Andy
-
aaargh, JavaScriptCore uses some non posix pthread extension pthread_attr_get_np it's not going to work without major hacking.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115282\"][{POST_SNAPBACK}][/a][/div]
If that fails you could try to build minimo, which is usually in a non-building state, but once notified Doug Turner fixes that within the hour
-
I have minimo and it's ok but a little unstable and quite large compared with gpe-minibrowser and the gte-webcore.
I think I'm going to persevere with the gte-webcore and see if I can take that posix thread 'non posix' stuff out of kjs... I saw that there was some criticism inside the KDE libs sources (kjs comes from kde and is part of the JavaScriptCore) about the API not being portable and it should be 'fixed' so it may be that someone has patched this already for some task.
- Andy
-
here are the tips given to me on #openzaurus to build gpe-minibroswer:
webcore : cvsdate 20050430 and two patches :
http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff (http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff)
http://www.kernelconcepts.de/~fuchs/oe/sto...e-loading.patch (http://www.kernelconcepts.de/~fuchs/oe/stop-load.image-loading.patch)
(not specially related to open-bsd )
edit: It might have been on #gpe on irc.freenode.net
-
here are the tips given to me on #openzaurus to build gpe-minibroswer:
webcore : cvsdate 20050430 and two patches :
http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff (http://www.kernelconcepts.de/~fuchs/oe/gdk-colorspace.diff)
http://www.kernelconcepts.de/~fuchs/oe/sto...e-loading.patch (http://www.kernelconcepts.de/~fuchs/oe/stop-load.image-loading.patch)
(not specially related to open-bsd )
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115314\"][{POST_SNAPBACK}][/a][/div]
Thanks pgas but the nature of this issue doesn't effect Linux since Linux implements an alternate non-posix extension to pthreads that the kjs source in JavaScriptCore utilises if __linux is defined so you wouldn't have the issue that I'm working on anyway.
Basically the call sequence is used to get the stack address of the thread, something which isn't in the posix specification and sounds just the sort of extension that OpenBSD wouldn't want since it is potentially open to misuse. I took a look at version of kdelibs that this version of kjs was derived from and there is a critical comment inside the source about 'changing this since it isn't portable'. - I guess I will trawl for kdelibs patches next... someone porting to QNX or something else may have a workaround.
here's the member function from kdelibs to show you...
299 void Collector::markCurrentThreadConservatively()
300 {
301 jmp_buf registers;
302 setjmp(registers);
303
304 #if __APPLE__
305 pthread_t thread = pthread_self();
306 void *stackBase = pthread_get_stackaddr_np(thread);
307 #elif defined(_WIN32) || defined(_WIN64)
308 NT_TIB *pTib;
309 #ifdef __GNUC__
310 __asm__("movl %%fs:0x18,%0"
311 : "=r" (pTib)
312 );
313 #else
314 __asm {
315 MOV EAX, FS:[18h]
316 MOV pTib, EAX
317 }
318 #endif
319 void *stackBase = (void *)pTib->StackBase;
320 #else
321 static void *stackBase = 0;
322 static pthread_t stackThread;
323 pthread_t thread = pthread_self();
324 if (stackBase == 0 || thread != stackThread) {
325 pthread_attr_t sattr;
326 #ifdef HAVE_PTHREAD_NP_H
327 // e.g. on FreeBSD 5.4, neundorf@kde.org
328 pthread_attr_get_np(thread, &sattr);
329 #else
330 // FIXME: this function is non-portable; other POSIX systems may have different np alternatives
331 pthread_getattr_np(thread, &sattr);
332 #endif
333 // Should work but fails on Linux (?)
334 // pthread_attr_getstack(&sattr, &stackBase, &stackSize);
335 pthread_attr_getstackaddr(&sattr, &stackBase);
336 assert(stackBase);
337 stackThread = thread;
338 }
339 #endif
340
341 int dummy;
342 void *stackPointer = &dummy;
343
344 markStackObjectsConservatively(stackPointer, stackBase);
345 }
EDIT:.... found a kludge for now..
/* OpenBSD workaround */
stack_t stack_info;
pthread_stackseg_np(thread,&stack_info);
void *stackBase=stack_info.ss_sp;
....
- Andy
-
OK, I finally got gpe-minibrowser running on OpenBSD, however, there are some major glitches possibly related to the version of Gtk that we use on OpenBSD or possibly related to some of the ugly hacks that I made. - it may be that the non portable pthread call that I am using isn't returning anything in which case the problem is much harder to fix and the JavaScript core won't work well without it.
Anyway on the site that I can get (www.google.com ) it does look pretty, however, it doesn't look enough like Gecko engine to work with FCKEditor yet (needed for moinmoin, and tested from a desktop Linux build) and it runs at about 13Mb of memory usage.
So in summary on OpenBSD konq-e works better for this sort of thing.
Oh, btw if anyone decides to repeat this test set up PLENTY of swap before you build NRCore, it balooned to 130Mb of swap space when building the CSS stuff.
- Andy
-
So I can afford to leave my Z building a little while longer and it looks like if you disable the MOZILLA_OFFICIAL and BUILD_OFFICIAL exports it may not sign the libraries which is where I was getting the segfault earlier.
This shlibsign program seems to be the bane of many mozilla builds with various builds even failing on i386 Linux systems too.
I'm trying with the prebuilt Mozilla having just stripped those tags out of the Makefile... odds on that Firefox will complain that the libraries aren't signed but I will try that first before cleaning and rebuilding since it takes ages to do that.
- Andy
-
Even w3m doesn't compile (will try to fix it if I have time, or I'll test again in 1-2 weeks and correctly report it to the ports team), ok, it's not graphical, but at least it's a text browser I'm used to use.
www/w3m has been fixed and builds fine. Some graphical support can be obtained by building the inline image version. make show=FLAVORS
-
Thanks! w3m is very sweat.
Next I will try to port Konquerer Embedded because it's (supposed to be) lighter and faster than Firefox.
-
Thanks! w3m is very sweat.
Next I will try to port Konquerer Embedded because it's (supposed to be) lighter and faster than Firefox.
Konquerer Embedded is in the ports collection, but I think it's an older version. Look at www/konqueror-embedded