Linking archive files with DDE

Hi all,

I’m progressing with building my first RISC OS C app, and now I want to link against SQLite.

So far I’ve managed to get my code compiling against the port by the really small software company:
https://www.reallysmall.co.uk/Pages/categories/riscos/database/sqlite.php

However when I run the code, it can open a database fine, but then crashes trying to parse a query (I think any query). Interestingly the provided sqlite CLI also crashes in the same place — somewhere in yy_reduce function. AFAICT my system should support this — I’m running RO 5.28 on a Pi400 (and hence should be using the 32 bit shared C library).

My debugging skills are not at the point where I can usefully diagnose why it is crashing, so I thought I’d try a different library. PackMan! provides a version of libsqlite that comes as a header file and an archive file (libsqlite3/a). Being new to C, it’s not obvious to me if it’s possible to link this during my app build, which is using the Norcroft DDE Makefiles. I can figure out how to link against pre-built object files, but not against this archive file format. Is it possible?

I guess another question: has anyone successfully managed to get SQLite linked to an app built with the DDE?

Thanks in advance!

Dave

It works OK after rebuilding everything with the latest DDE.

> It works OK after rebuilding everything with the latest DDE.

That sounds promising.

My struggle with that in practice is that the provided Makefiles, when dragged onto Amu!, don’t actually succeed in building. This is probably due to missing dependencies. As an example building SQLite complains about lack of CLibSupport … so I got that from the really small website as well, but that also doesn’t include object files and compilation fails as well. This time with `file “sys/types.h” wouldn’t open.

I will continue to plug away at gaining understanding of how all this hangs together and what I’m missing in my environment to be able to compile Sqlite.

Dave

The Makefile32 files need the include paths updating. Change C32: to C:, TCPIPLibs32: to TCPIPLibs: and OSLib: to OSLib:oslib.

You will also need OSLib and OSLibSupport.

Thank you Chris.

This got me off and running.. I’ve now got all the dependencies, figured out how to compile CLibSupport, SQLite, and now my app launches without crashing! Amusingly it does write some white text on black background over a small portion of the desktop at launch, but I will assume this is something I’ve done wrong! Anyway .. progress!

It’s been years since I’ve played with this but I wonder how much work would be involved in a) making it accessible from BASIC, and b) updating it to a much newer SQLite version.

A few years ago I tried to build the latest version from scratch, but didn’t get very far with it. I wasn’t aware of this existing version at the time; updating it might be easier than redoing everything.

I wonder whether a good plan might be to wrap the whole thing in a module. Not only does that take care of BASIC accessibility but also reduces memory usage once you have more than one SQLite-based app running. Of course, it’ll probably introduce its own problems :)

I wonder whether a good plan might be to wrap the whole thing in a module.

Wrapped in a module and then eventually shipped with the OS would be great. It would be nice to have this as part of the standard RISC OS distribution, so that apps built in C or BASIC could use it, instead of people building their own less robust solutions.

I’ve had a little nosey at the source and it “shouldn’t” be too difficult to update it to a later version. When compared with the original 3.3.6 source¹, very few files have been modified and the bulk of the customisations are in os_riscos.c, which itself is a modified copy of os_unix.c.

¹ I’ve dropped it onto my server to make it a bit easier to find.

Wrapped in a module and then eventually shipped with the OS would be great.

I agree.

It seems that Gerph’s been down this road too.

I had a bit of a play and now have a ‘cleaner’ build. Aside from the os_riscos files, the only changed files are now os.h and shell.c. To use ROOL’s words, “makefile recreated from fragments”, and there is no longer a dependency on CLibSupport (which was only #included but not actually used).

I’ve only done a cursory test (create database, create table, add data, select data) but it all works so far! Next on the agenda is either to try updating it to a newer version, or to try getting the official tests to run (although this may not be practical).

I do have a not-technically-SQLite-related question though. Compilation fails without -ec to suppress some errors. Is there an ‘official’ way of passing this through to CC from a shared makefile? At the moment I’ve just put it on the CINCLUDES line, which feels a little hacky.

This sounds amazing! Happy to help test too.

I do have a not-technically-SQLite-related question though. Compilation fails without -ec to suppress some errors. Is there an ‘official’ way of passing this through to CC from a shared makefile? At the moment I’ve just put it on the CINCLUDES line, which feels a little hacky.

CFLAGS is where all the other switches are held, so

CFLAGS += -ec

should do the trick.

That did indeed do the trick. Thanks :)

the only changed files are now os.h and shell.c

Interestingly, shell.c was from version 3.0.8. I’ve updated it to the 3.3.6 version and it appears to still work correctly. This file is ‘special’ in that it’s not part of SQLite itself, but rather contains its command-line interface, and it assumes a Unix-like system in a few places. Unfortunately it’s not possible to use an untouched copy; even when using Unixlib to get some of the ‘missing’ functions it still makes assumptions like trying to read a file named ~/.sqliterc.

Still, the main SQLite library is completely untouched other than the files beginning with “os” :)

This means that it’s now in a ‘clean’ state and should be fairly easy to upgrade to a newer version. If all goes well then I’ll have some files for download in the next day or two!

This means that it’s now in a ‘clean’ state and should be fairly easy to upgrade to a newer version. If all goes well then I’ll have some files for download in the next day or two!

I really shouldn’t open my big mouth without checking things. I assumed that the OS-specific code would change relatively infrequently and that it’d be fairly simple to update SQLite itself. I hereby revise “next day or two” to “when it’s done” :)

With that said, in the interim here’s 3.3.13 (the last version before it all changes!) built with a modern DDE. The command-line shell is also included.

Edit: I don’t guarantee that this is bug-free and I suggest keeping a backup of any database files. Doubly so after seeing this code, which may be legitimate, but looks wrong at a glance:

/*
** Truncate an open file to a specified size
*/
int riscosTruncate(sqlite3_file *id, i64 nByte){
  _kernel_swi_regs regs;

  regs.r[0] = OSArgs_SetExt;
  regs.r[1] = ((riscosFile *)id)->h;
  regs.r[2] = 0;

  if (_kernel_swi(XOS_Args,&regs,&regs) != NULL) {
    return SQLITE_IOERR_TRUNCATE;
    }

  return SQLITE_OK;
}

I now have the current version (3.35.4) up and running. I’ve found a few things that don’t work correctly so I’m not going to release it just yet, but things are progressing :)

Thanks for the continued effort Chris!

I’ve created an announcement thread for further SQLite news.