Absolua

RiscLua83 now has the !Absolua utility, which in this case transforms a RiscLua program to an ELF file. You need !SharedLibs to run it, but not RiscLua83. The meaning of standalone was always equivocal.

!Absolua utility, which in this case transforms a RiscLua program to an ELF file

by the name was it aimed at making an absolute file, by using elf2aif?
I’m busy with things other than lua, but I noticed via google there are some lua scripts around for doing OAUTH2 for the sakes of gmail (and others now). Other platforms use python scripts, which is a bit cumbersome for our use, but an absolute file, even better for packaging.

by the name was it aimed at making an absolute file, by using elf2aif?

I used to use the Acorn C/C++ compiler, which made AIF (Absolute) files. But I had to change to GCC and ELF files to have hard floats and VFP. The name has stuck as a historic curiosity, yes. Absolute is a rather odd choice of terminology, anyway. I am sorry to say that GCC is much less compact, so the Lua runtime adds on a couple of 100K, where before it was less than that figure. There is no point to Absolua unless you are wanting to package up a grand oeuvre to be used somewhere with RiscLua not installed.

wanting to package up a grand oeuvre to be used somewhere with RiscLua not installed.

Hmm, converting an elf to aif also means you dont need !SharedLibs installed, just the sharedulib module. It is not always the case, but for most utility type binarys elf2aif also reduces the size quite a bit.
I get what you mean, you are including the runtime with the program, it depends how much of lua is needed to do that, does it only pull in what is needed etc. You wouldn’t want to package the BASIC module with every BASIC program either.

I must reread the elf2aif docs. I thought it only worked with statically compiled ELF files that had no unresolved dependencies. I agree that the best way to package would be to bundle only those libraries that are actually needed (what else are shared objects files for), but I don’t know how to automate the linking process properly. I guess it would need the bundling program to write an ld-script or something.

I must reread the elf2aif docs. I thought it only worked with statically compiled ELF files that had no unresolved dependencies.

You’re correct, so it’s probably not worth going back to read them again.

Clearly you could statically link the code, and then use elf2aif. There’s no reason why you must use shared libraries for hard floats and VFP.

It is not always the case, but for most utility type binarys elf2aif also reduces the size quite a bit.

This surprises me, as I was under the impression that all elf2aif did was lift the code from the ELF file and splice it into enough “stuff” to make it look like AIF. The actual code is the same, and the size is the same.

This surprises me, as I was under the impression that all elf2aif did was lift the code from the ELF file and splice it into enough “stuff” to make it look like AIF. The actual code is the same, and the size is the same.

ELF files can contain more than just code, though – symbol tables for dynamic loading/linking (not sure if they’ll be present in a static elf?), relocation tables, debug symbols, etc. elf2aif will throw all of that away so that it’s just the code that remains.

Other big savings can come from dead code stripping, but I think that’s performed by the linker rather than elf2aif.

Absolute is a rather odd choice of terminology

The proper name of modules is relocatable modules (hence *RMsomething). Nobody bothers with that mouthful as modules are, by their nature, relocatable.

Absolute, on the other hand, executes from an absolute address. Unlike static code that runs from a defined and fixed address (like anything *Saved), the base address of absolute is fixed by the system and is immutable. Absolute runs at &8000. No if, but, or otherwise. It is absolutely there and nowhere else.

Hence the name “absolute”.

The filetype is easy to remember too. &FF because it’s a system internal type, and 8 because of the fixed base – thus &FF8

The filetype is easy to remember too. &FF because it’s a system internal type, and 8 because of the fixed base – thus &FF8

Perhaps we should call it Absolate?

Just an off-the-cuff idea!

Great clarity from Steve, Rick and Jeffrey.

It sounds like the Absolua ELF is standalone in the sense it doesn’t need Lua desktop program to run it, but it will still need the Lua so libraries installed in !SharedLibs.
Could be a positive advantage of one less process to run?

I think GCC can use either or both solibs and static libs when building a static binary OK.
It is when building libraries that mistakes can be made.
The autobuilder can use libtool to keep on eye on things, otherwise you have to find out the hard way later when trying to link.
A library like zlib built wrong can infiltrate later built libraries like a virus, and you have to start again from scratch.

Tiny utility programs can be built smallest with -mlibscl, are absolute, and only need sharedClib, Unix standard library functions that aren’t available in libscl need SharedULib as well, the absolute file is bigger.
With many unixlib libraries involved, a /shared/ ELF executable
will be smallest by far.

but it will still need the Lua so libraries installed in !SharedLibs.

Of which there are none. Have a look in !SharedLibs. RiscLua 6 had the riscos and lpeg libraries as shared, but all the RiscLuas since then come with them already linked. The Lua standard libraries are always already linked, which is the official recommendation. It is only the Unix standard library functions that are not.

The only reason GCC, and so the Unix library, is used is to provide floating point in hardware. I compile for myself private versions, using the AcornC/C++ compiler, with no floating point arithmetic at all, for use in applications that do not need noninteger numbers. The AIF file is then less than 70K.

Absolua now only adds 191K to your program, as it adds only the virtual machine, leaving out the compiler. The downside is that your program cannot use load or loadfile which use (are, in fact) the compiler.