Help Me Put My Old Z To Use Again!

[ArchiMark]

Between your build experiences and mine recently (see other thread...), it seems like building on the Zaurus is a PITA.....timewise and otherwise....

Would think it would be much more practical if we could build on a faster computer (which usually has a larger display too for looking at text about build process...) and then transfer resulting build to the Zaurus to use.

Assume this would require setting up a cross-compiler on computer, right?....

I know there's the other method using NFS server, but that would require having Zaurus connected to other computer all the time during build process, correct?

If possible, I'd like to avoid having to have Zaurus running all the time....

Meanwhile, look forward to additional updates on your build experiences.....

Thanks!

Mark

[TronDD]

Assume this would require setting up a cross-compiler on computer, right?....

I know there's the other method using NFS server, but that would require having Zaurus connected to other computer all the time during build process, correct?

Yes.  I've never done that for the Z nor in OBSD.  Search the forum, someone must have done it.

Yes.  An NFS server only gives you, essentially, an external hard drive to build on.  It still compiles with the Z's cpu and memory.

Tim.

[ArchiMark]

Assume this would require setting up a cross-compiler on computer, right?....

I know there's the other method using NFS server, but that would require having Zaurus connected to other computer all the time during build process, correct?

Yes.  I've never done that for the Z nor in OBSD.  Search the forum, someone must have done it.

Yes.  An NFS server only gives you, essentially, an external hard drive to build on.  It still compiles with the Z's cpu and memory.

Tim.

Thanks, will check it out....

Mark

[TronDD]

Ok, tried skipping the cmake build by installing the generic arm package.  Seemed to go fine until I tried to build graphite2.  It builds with cmake and gets a segfault trying to run the install target.  (It's built, I just need to install it! Arg!)

I am assuming something it's right with arm cmake on the Z so I am trying to get it to compile natively.  The only problem compiling it (so far) is a bit of code that tries to find the current path and the executable it just built.  The default behavior was returning an empty string for the path.  I commented out some APPLE defines so it will run that code (hey, it's BSD based, so should be relevant) which does pretty much the exact same thing, and it works, but is one directory level short.  Something do to with where the command was initiated from versus where ports builds to, I guess.

It takes a good 20 minutes to build this one file so it's tedious to debug.

Tim.

[ArchiMark]

Yep, had cmake issues too....

Let me know how it goes....

[TronDD]

I found a bug in cmake, fix it, the build started seg faulting.   Undid the fix, it continued to seg fault.  Had to blow it all away and start the build over to see if the crash goes away.  A full build, to the point it hits the bug, is 24 hour or more.    I don't even know if there will be other bugs after this one or if it'll just seg fault like the arm package.

Tim.

[TronDD]

So I shortcutted around this cmake issue by simply returning what I wanted out of the function and now get a crash deleting a map or vectors or something that's beyond me.    I think I might have to give up.

Last ditch effort is to pull the latest cmake release and build it and see what happens.

Tim.

[ArchiMark]

So I shortcutted around this cmake issue by simply returning what I wanted out of the function and now get a crash deleting a map or vectors or something that's beyond me.    I think I might have to give up.

Last ditch effort is to pull the latest cmake release and build it and see what happens.

Tim.

Too bad about cmake.....wonder why this is such a problem....

Mark

[TronDD]

Ports mailing list to the rescue (I hope).

http://article.gmane.org/gmane.os.openbsd.ports/63302

I accidentally ran 'make clean=depends' on a port that required cmake so it blew away all my hackery.   I've applied the patches from the mailing list, but it'll be a day or so to recompile, then I might still have to fix the original bug I was working on as I didn't see anything about that in the mailing list discussion.

Tim.

[ArchiMark]

From reading the posts at http://thread.gmane.org/gmane.os.openbsd.p...270/focus=63302 it looks like there is a workaround?.....

From: Stuart Henderson <sthen <at> openbsd.org>
Subject: Re: cmake diff to disable elf parser and ninja (Was: arm port build failures)
Newsgroups: gmane.os.openbsd.ports
Date: 2013-08-21 22:32:58 GMT (27 weeks, 4 days, 17 hours and 34 minutes ago)

On 2013/08/21 15:03, Stuart Henderson wrote:
> On 2013/08/21 15:30, David Coppa wrote:
> > On Tue, 20 Aug 2013, Stuart Henderson wrote:
> >
> > > On 2013/08/20 08:25, Stuart Henderson wrote:
> > > > On 2013/08/20 08:50, David Coppa wrote:
> > > > > On Mon, Aug 19, 2013 at 11:50 PM, Stuart Henderson <sthen <at> openbsd.org> wrote:
> > > > >
> > > > > > these ones all use cmake which has a common segfault on arm since
> > > > > > the move to enabling the elf parser.
> >
> > Comments on the following diff?
>
> In the absence of any better ideas, this makes sense to me, I'll give it a try.

yep, that works.

> > #0  cmELF (this=0xbfff4674, fname=0x4337438c "/usr/lib/libz.so.4.1")
> >     at basic_ios.h:124
> > 124           { return _M_streambuf_state; }
>
> I get the impression this is something which shouldn't be segfaulting though..

as a workaround: OK.

[ArchiMark]

Still haven't figured out how to get Dillo to show URL bar, and zoom out to see more of page....or get horizontal scrollbar to do this.....

Meanwhile, was looking through older threads here and found this post from 2007:

[img]http://general.sc35.info/artlists/firefox_eats_ie.jpg\" border=\"0\" class=\"linked-image\" /]

Here's the latest OpenBSD Mozilla-firefox package:

Mozilla-firefox-2.0.0.5.tgz

along with the development sources: (optional download)

Mozilla-firefox-devel-2.0.0.5.tgz

All Mozilla-firefox sources were compiled with the following flags:

CFLAGS="-mcpu=xscale -mtune=xscale -O2 -pipe"
CXXFLAGS="-mcpu=xscale -mtune=xscale -O2 -pipe"

The Java and Flash plug-ins I've previously compiled work flawlessly with this updated version.

Do you think we can get firefox built again?.....

Know it would be slower than Dillo.....

[TronDD]

I was able to build glib2 natively with the patches from here:
http://mail-index.netbsd.org/pkgsrc-bugs/2.../msg051683.html

I'm going to reconstruct my environment from there in case the generic arm package was causing some of my problems.

Tim.

[wario]

No way! I'm wanting to put my z back to use too.

Of course I forgot my root password too. Can you remind me to reset that?

Thanks.

Edit: I am using cacko "katherine".

[TronDD]

No way! I'm wanting to put my z back to use too.

Of course I forgot my root password too. Can you remind me to reset that?

Thanks.

Edit: I am using cacko "katherine".

I'm not familiar with cacko.  Can you boot into single user mode and reset the password there?

[ArchiMark]

Hi Wario,

For cacko related info, you should search on the cacko forum section....  

Your other option is to reflash cacko, then follow OpenBSD on Zaurus instructions and then you can join Tim and I in our 'OpenBSD on Zaurus' adventures....