old desklib app recompile.. template file wrong?

I stumbled across a 26bit desklib app
moontool

and I thought it would be an easy recompile for ARMv7, especially since there was already an lyonix version…

I was wrong. I’ve been banging my head against this for days, and I admit defeat.

in Window_CreateWithFlags()…

I changed Template_find() to Template_Clone(). Template_find() was giving 0-page pointers.

But it’s telling me (window_block *wb→numicons) is 580? The first template window is MoonTool and it has 22 icons, the template file has 77 icons total. So I can’t see where 580 is coming from.

I have looked at the Templates file in formed, wined, winedit, and even regenerated it via ccres but I still get the wrong number there.

Is the Templates file corrupt? Is desklib doing something wrong, or being used wrong?

Help!?!?!

Both Iyonix builds run on the RPi1 in armv5 mode so maybe the Template file really is OK?

This is how my build of 3.27 fails. Using DDE30 and DeskLib 2.80.

Bad juju: hex not understood.

Unexpected termination (e.g. abort() function)

Postmortem requested
fc187e44 in shared library function
fc187ef8 in shared library function
fc18aca0 in shared library function
  Arg1: 0x00000052 82
981c in function hdigit
  Arg3: 00000000 0
  Arg2: 00000000 0
  Arg1: 0x0000a2a0 41632 -> [0x6e6f6f4d 0x6c6f6f54 00000000 0x00011228]
9904 in function Window_CreateWithFlags
  Arg2: 0x000145ec 83436 -> [0x0001460c 0x00014621 0x00014624 00000000]
  Arg1: 0x00000003 3
9f54 in function main
  Arg2: 0x00009db0 40368 -> [0xe1a0c00d 0xe92ddbf3 0xe24cb004 0xed6d4206]
  Arg1: 0x000140f0 82160 -> [0x65626f3c 0x69642479 0x212e3e72 0x496e7552]
fc17bc84 in shared library function
cc10 in anonymous function

See line 984 in c.!RunImage

Oh, I remember this little “annoying thing”. It’s a nice program, but DeskLib has changed a lot since it was written. Someone asked me to update it for them to run on an ARMiniX, I think, about 7 years ago.

I think we did succeed (although I may be wrong). But I cannot remember how. I will look and see if I still have it. I remember a lot of frustration, that’s for sure.

This is how my build of 3.27 fails. Using DDE30 and DeskLib 2.80.

Am I misremembering or did Rick Murray mention having done things to modify DeskLib because of certain faults?

I’ve just built it using GCCSDK and the current DeskLib from RISCOS.info (which I have around thanks to WinEd), and it seems to run fine on a Titanium with no modifications. There’s a small window showing an image of the moon, which I assume is what it does.

I’ve got other things to do in the next couple of hours, but I’ll follow up later with more details. In the meantime, check that your DeskLib has also been re-built from source using a new compiler.

the “bad juju” message is because it calls template_find() instead of template_clone(). template_find() is returning a 0 page pointer and hdigit() is finding “DEFREFERENCE NULL”
I should have mentioned sorry, DDE28 and desklib from packman afk atm cant check exact version

the “bad juju” message is because it calls template_find() instead of template_clone().

Except that it works perfectly here using Tenplate_Find(), and not Template_Clone(), having compiled the lot to be ARMv7 safe. All that I changed was the Makefile, to allow it to build using GCC.

Are you sure that your DeskLib binary isn’t compiled for older hardware?

There’s a small window showing an image of the moon, which I assume is what it does.

Yup. Click the window for nerdy info.

Built and works fine for me using the DDE and my DeskLib32 (v2.30/RM32) → http://heyrick.ddns.net/desklib/

Had to change two things: First, amend the MakeFile to reference o.DeskLib32 instead of o.DeskLib, and secondly there is a redefinition of abs(), so I commented out the one that the compiler was complaining about.

Am I misremembering or did Rick Murray mention having done things to modify DeskLib because of certain faults?

Various things, yes. But in my experience, weird and illogical failures seem to come from builds that do faulty things like depend upon rotated unaligned loads. You should be using a recently compiled version of DeskLib, or rebuild it yourself.

they always seem to end up being more work than working directly with the system.

I’m not even going to bother…

I remember a lot of frustration, that’s for sure.

Wow. I loaded it into Zap, hit Sh^C, fixed the redef problem, hit Sh^C and then ran the newly built program. If only everything was that easy. ;-)

Thanks for the pointer, Willard. It’s a useful little program.

OK… Desklib 2.80 here, last DDE version from packman. Skuld only knows what hardware it was compiled for…

I’ll upgrade to Rick’s version and try again.

I admit I’m not enthused about trying to build my own copy of something as big as Desklib.

I’ll upgrade to Rick’s version and try again.

Some might suggest an alternative word in place of “upgrade”. ;-)

I admit I’m not enthused about trying to build my own copy of something as big as Desklib.

For my one, it should be a case of:

• Unpack the !DeskLib stuff
• Unpack the !DLSources stuff (note the “build_desklib” Obey file)
• Double-click the build_desklib file

That ought to be all you need.

• You’ll maybe get a few seconds of hourglass
• A TaskWindow will open spewing out gibberish as the parts of the library are built.
• A Throwback will open with some (three) warnings. Nothing to stress over.
• After a while (depends on your machine) a second TaskWindow will open telling you that the library is being built.
• Then it’ll give the reassuring message “DeskLib build process completed, now go check that it actually worked. ;-)”.

Within !DeskLib.o will be “DeskLib32” which will be the newly built library.

That said, mine should be in a suitable state for current machines.
I’m surprised the GCCSDK one isn’t as well.

Yay! Success!!!!
Dropping Ricks o.desklib32 into 2.80’s desklib: didn’t work but fully installing Rick’s 20200511 release and rebuilding moontool from scratch did!

Thank you Rick!!!! You Da MAN!!!!

Desklib 2.80 here, last DDE version from packman.

The version in PackMan is ELF, for GCC, so I’m surprised that it’s even linking. Otherwise, if you’ve held on to an AOF copy, it’s going to be from pre 2009 or so — by then, it was clear that the official releases were being structured for GCC use only (although there are still UnixLib and SCL versions).

Dropping Ricks o.desklib32 into 2.80’s desklib: didn’t work

It probably won’t, because unhelpfully we now have a forked DeskLib: the one in SVN at RISCOS.info, and Rick’s.

I’m surprised the GCCSDK one isn’t as well.

It is. As I noted in my earlier email, it took about five minutes to build a working MoonTool with the GCCSDK — and most of that was renaming h. and c. into .h and .c, then adapting WinEd’s makefile to do the necessary.

The version in PackMan is dated 2014, so should be ARMv7-safe, but is ELF format, not AOF.

package “desklib” is ELF
packages “desklib-core”, “desklib-user” and “desklib-examples” are AOF, and apparently not ARMv7 safe.

Makes me nervous about !oslib, !unixlib, and !slidinghp….

packages “desklib-core”, “desklib-user” and “desklib-examples” are AOF, and apparently not ARMv7 safe.

Ah. Yes. They appear to have been getting hand maintained and built by Adam Richardson, so when he moved on to other things I suspect they didn’t see any more love. The last changes in SVN were around the time of the last WinEd releases, so 2008-9.

Makes me nervous about !oslib

OSLib (but not OSLibSupport) shouldn’t be a problem — you can get the latest version in AOF format from http://ro-oslib.sourceforge.net/, and I’ve used it for building all of my C Tutorial code with Norcroft recently.

So someone needs to Kill, Delink, and Delete the concept of ELF on RISC OS, yet again.

Not really. As I wrote earlier: five minutes to build a new version of MoonTools… Using an ELF library.