Precompiled GPL SharedCLibrary?
Simon Willcocks
I'm messing about with getting RO applications to run on ROLF, again.
I don't want to have anything to do with RISC OS source code, but all the
modules provided on the ROOL website are squeezed using a propriatory
algorithm. There is, however, a application called SqzUnSqz that is freely
available and contains the program unmodsqz that I could use to unsqueeze
modules for the emulator, except for the minor detail that it's written in C
and the shared C library from the ROOL site is squeezed....
Looking back a few years, there was a GPL (with a "Runtime Exception")
version of the library written by Graham Shaw, which should do nicely. I
found the source on the RiscPkg.org svn server and had a go at compiling it
last night. Unfortunately, I don't seem to have found the right combination
of GCC tools and libraries to get it to compile, and I was wondering if
anyone knew of a pre-compiled version kicking about the place I could use
instead?
Thanks,
Simon
(By the way, I'm impressed with the shared library aspects of the recent
GCCs.)
--
ROLF - The RISC OS Look and Feel on Linux.
http://stoppers.drobe.co.uk
http://ro-lookandfeel.blogspot.com/
Peter Naulls
> Hi,
>
> I'm messing about with getting RO applications to run on ROLF, again.
>
> I don't want to have anything to do with RISC OS source code, but all the
> modules provided on the ROOL website are squeezed using a propriatory
> algorithm. There is, however, a application called SqzUnSqz that is freely
> available and contains the program unmodsqz that I could use to unsqueeze
> modules for the emulator, except for the minor detail that it's written in C
> and the shared C library from the ROOL site is squeezed....
I'm not sure of the specific problem here, but presumably you mean
this: http://www.martinkd.freeuk.com/unsqueeze.html
Which still contains CTL binary components.
> Looking back a few years, there was a GPL (with a "Runtime Exception")
> version of the library written by Graham Shaw, which should do nicely. I
> found the source on the RiscPkg.org svn server and had a go at compiling it
> last night. Unfortunately, I don't seem to have found the right combination
> of GCC tools and libraries to get it to compile, and I was wondering if
> anyone knew of a pre-compiled version kicking about the place I could use
You don't say what specific problems you are having with compiling it -
and although I happen to know the URLs involved, it'd be a good idea
to specify them for others:
http://source.riscpkg.org/websvn/listing.php?repname=SharedCLibrary&path=%2Ftrunk%2F&rev=0&sc=0
What I can tell you is that Graham's stuff uses GCC 3.4 era code (or
even older), so that it'll be Acorn style assembler. I compiled his
GPL filer module with new GCC, and the situation will be much the
same; you'll need to use 'asasm' for the assembler, and stuff like
this in your makefile:
AS = asasm
CFLAGS = -mhard-float-mthrowback -mlibscl -mmodule \
LDFLAGS = -mhard-float -mlibscl -mmodule
CMHGFLAGS = -zoslib -zbase -tgcc
Modify as you see fit. You'll need to specific OSLib in there somewhere
too
> (By the way, I'm impressed with the shared library aspects of the
recent GCCs.)
Me too, alas I've been the only one testing the developments until
very recently, so there's still a lot of nagging detail to be resolved.
Simon Willcocks
Peter Naulls <pe...@chocky.org> wrote:
> Simon Willcocks wrote:
> > I'm messing about with getting RO applications to run on ROLF, again.
> >
> > I don't want to have anything to do with RISC OS source code
>
> I'm not sure of the specific problem here, but presumably you mean
> this: http://www.martinkd.freeuk.com/unsqueeze.html
Yes.
> Which still contains CTL binary components.
True, but it's freely downloadable and I can't see anywhere that says that
it can't be run on operating systems other than RISC OS. In fact, it says:
* This is PD Software, you may copy and distribute it freely, *
* provided you keep the Castle Licence Document with it. *
I think that's a lot different from delving into the source code to extract
the code (or even just the algorithm, which probably includes a proprietary,
copyright, table of values) to do the decoding and incorporating it into
ROLF. I don't want to produce anything that is or appears to be derivative
work from anything RISC OS.
> > Looking back a few years, there was a GPL (with a "Runtime Exception")
> > version of the library written by Graham Shaw, which should do nicely. I
> > found the source on the RiscPkg.org svn server and had a go at compiling it
> > last night. Unfortunately, I don't seem to have found the right combination
> > of GCC tools and libraries to get it to compile, and I was wondering if
> > anyone knew of a pre-compiled version kicking about the place I could use
>
> You don't say what specific problems you are having with compiling it -
> and although I happen to know the URLs involved, it'd be a good idea
> to specify them for others:
>
> http://source.riscpkg.org/websvn/listing.php?repname=SharedCLibrary&path=%2Ftrunk%2F&rev=0&sc=0
That's it. The reason I didn't link to the source or list the errors I had
was because I was only looking for a pre-compiled copy to use, rather than
advice on how to compile it.
That said, since there doesn't appear to be one, I went back to compiling
and your advice has got me a lot farther, thanks.
> What I can tell you is that Graham's stuff uses GCC 3.4 era code (or
> even older), so that it'll be Acorn style assembler. I compiled his
> GPL filer module with new GCC, and the situation will be much the
> same; you'll need to use 'asasm' for the assembler, and stuff like
> this in your makefile:
> AS = asasm
> CFLAGS = -mhard-float-mthrowback -mlibscl -mmodule
> LDFLAGS = -mhard-float -mlibscl -mmodule
> CMHGFLAGS = -zoslib -zbase -tgcc
>
> Modify as you see fit. You'll need to specific OSLib in there somewhere
> too
Replacing as with asasm in the makefile with GCCSDK 4.1.1 release 2 and
OSLib690 has problems with opening OSLib header files:
asasm -objasm -throwback -module -apcs32 -apcsfpv3 -target xscale -IOSLib:
-Ilibc/internal -o handle_done.o handle_done.s
Error: Cannot open file "oslib/OSModule.Hdr" at line 6
Error: Cannot open file "oslib/MessageTrans.Hdr" at line 7
Just trying an old GCC (3.4.6) to build it, and modifying the .d files
generated from fixdeps, I've got a relocatable module!
I'll see if it works, now....
Thanks, again,
Simon
For future reference, I created an obey file in the SharedCLibrary root
directory called FixFix containing the one line:
sed -i 's/\( [a-zA-Z0-9\^\.]*\)\([hc]\)\.\([a-zA-Z0-9_]*\)\>/\1\3\/\2 /g' %*0
It just changes .h.filename to .filename/h, and the same for .c files;
without it the make version 3.8 doesn't understand the rules.
And changed the .dd.d: commands in libc.Makefile/modules to:
.dd.d:
$(FIXDEPS) $* < $< > $@
^.^.fixfix $@
There must be a way of putting the sed command in the makefile, but I wasn't
able to work it out.
I also copied libgcc from !gcc.bin.arm-riscos-aof.3_4.apcs32.rma.libscl.o.
into a new 'a' directory under the SharedCLibrary root, as instructed by the
SharedCLibrary README file. (Actually, that's a guess because there are two
other libgcc files, but the rma part of the pathname lead me to choose that
one).
Peter Naulls
>
> I also copied libgcc from !gcc.bin.arm-riscos-aof.3_4.apcs32.rma.libscl.o.
> into a new 'a' directory under the SharedCLibrary root, as instructed by the
> SharedCLibrary README file. (Actually, that's a guess because there are two
> other libgcc files, but the rma part of the pathname lead me to choose that
> one).
Yes, this is a bit strange. GCC certainly knows how to find its libgcc,
and you run the risk of using the wrong one. I strongly recommend you
leave out explicit mention.
Having said that, I also strong recommend using what is now an
old compiler, GCC 3.4.6. I know that converting to GCC 4.1 is a
little non-obvious, but there are speed benefits, and there's been
an outrageous number of UnixLib fixes (although not used in this
specific case)
Simon Willcocks
Peter Naulls <pe...@chocky.org> wrote:
> Simon Willcocks wrote:
>
> >
> > I also copied libgcc from
> > !gcc.bin.arm-riscos-aof.3_4.apcs32.rma.libscl.o. into a new 'a'
> > directory under the SharedCLibrary root, as instructed by the
> > SharedCLibrary README file. (Actually, that's a guess because there
> > are two other libgcc files, but the rma part of the pathname lead me
> > to choose that one).
>
> Yes, this is a bit strange. GCC certainly knows how to find its libgcc,
> and you run the risk of using the wrong one. I strongly recommend you
> leave out explicit mention.
I would, but I didn't put it in there. The final link is done by Acorn's
link with the options "-RMF -RO-base 0", perhaps you couldn't get gcc to
pass through the required flags, at the time?
> Having said that, I also strong recommend using what is now an
> old compiler, GCC 3.4.6. I know that converting to GCC 4.1 is a
> little non-obvious, but there are speed benefits, and there's been
> an outrageous number of UnixLib fixes (although not used in this
> specific case)
Presumably "recommend against using...". Again, for any other project, I
probably would, but this one originated with the old GCC, there's little
dependency on other libraries (none on UnixLib) and it was (presumably)
tested with the old GCC.
Also, it's probably only going to be used with one program, unmodsqz, to
unsqueeze up-to-date modules from ROOL before running them through an
emulator.
My next problem is the use of floating point instructions. Ideally, I would
like some FOSS code that decodes the appropriate coprocessor instructions
and uses C code to implement them. Anyone?
Simon
Theo Markettos
> My next problem is the use of floating point instructions. Ideally, I would
> like some FOSS code that decodes the appropriate coprocessor instructions
> and uses C code to implement them. Anyone?
In the ARM code being decompressed, or the compiled C binary? When
compiling with GCC -msoft-float will build floating point code as integer
instructions.
Theo
Simon Willcocks
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
This is for use with existing RISC OS application ARM code that already
contains FPU instructions. If I can recompile things, I can probably
recompile them into native code.
The interface to the emulator consists of a globally-accessable set of
variables for the registers and PSR, plus a routine to call that basically
says "emulate an ARM processor until you come across something that you
can't cope with"; on exit, the "registers" have been updated as you'd
expect. Internally, the standard ARM instruction set is decoded and
translated into x86 machine code on the fly, but doesn't deal with SWIs,
MSR/MRS, coprocessor instructions, or anything unknown or undefined; those
are left up to the calling code. It makes for quite a compact emulator
that's reasonably quick (there's still room for improvement, though).
The obvious approach is to have an array of floating point values for the
FPU registers, and use C code to perform the FP operations themselves. If
they're all supposed to be IEEE-something complient, that should work out OK
by itself. Possibly.
Here goes...
Peter Naulls
I don't know if this is as relevant here, but module/SCL code from GCC
is hard float, because of what it needs to interact with it.
For GPL FPE support, you can dig up the stuff from ARM Linux 2.4 or so
which has a couple of emulation modules (might still be there in 2.6).
Modern ARM Linux systems use soft-float.
Simon Willcocks wrote:
> I would, but I didn't put it in there. The final link is done by Acorn's
> link with the options "-RMF -RO-base 0", perhaps you couldn't get gcc to
> pass through the required flags, at the time?
It's possible that drlink didn't support the require voodoo, or that
this dates from 2.95 days - you'd have to ask Graham to be sure.
However, the binutils linker is very flexible, but I won't guess offhand
what the required magic would be for that.
> Presumably "recommend against using...". Again, for any other project, I
> probably would, but this one originated with the old GCC, there's little
> dependency on other libraries (none on UnixLib) and it was (presumably)
> tested with the old GCC.
Understood. I guess this point here is that if you need to do any
development here and/or coordinate with others that a modern setup
really would be best, even if the aims of those others might
be quite different. Certainly, if there are toolchain issues,
we wouldn't be able to support you.
Simon Willcocks
Peter Naulls <pe...@chocky.org> wrote:
> Theo Markettos wrote:
> > Simon Willcocks <simon.w...@t-online.de> wrote:
> >> My next problem is the use of floating point instructions. Ideally, I
> >> would like some FOSS code that decodes the appropriate coprocessor
> >> instructions and uses C code to implement them. Anyone?
> >
> > In the ARM code being decompressed, or the compiled C binary? When
> > compiling with GCC -msoft-float will build floating point code as
> > integer instructions.
>
> I don't know if this is as relevant here, but module/SCL code from GCC
> is hard float, because of what it needs to interact with it.
>
> For GPL FPE support, you can dig up the stuff from ARM Linux 2.4 or so
> which has a couple of emulation modules (might still be there in 2.6).
> Modern ARM Linux systems use soft-float.
That sounds interesting, do you happen to know if they're in C or assembler?
I'd have thought that perhaps they'd have to be assembler for raw speed.
In any case, I've sort-of decided to just use the RO FPEmulator module; it
should be a matter of implementing the unknown instruction processor vector
in the emulator, but I've hit a snag in that the FPEmulator's code simply
calls the old vector, which I hadn't provided any code for yet.
> Simon Willcocks wrote:
>
> > Presumably "recommend against using...". Again, for any other project, I
> > probably would, but this one originated with the old GCC, there's little
> > dependency on other libraries (none on UnixLib) and it was (presumably)
> > tested with the old GCC.
>
> Understood. I guess this point here is that if you need to do any
> development here and/or coordinate with others that a modern setup
> really would be best, even if the aims of those others might
> be quite different. Certainly, if there are toolchain issues,
> we wouldn't be able to support you.
I understand that. You've been very helpful. What I want to achieve (and
think I have, now) is to compile the module exactly once, for use in a very
constrained situation. With that in mind, I think spending time on anything
other than the bare minimum to achive a sufficiently working module would be
a waste of time. (The general need for a GPL shared C library module has
vanished with the creation of ROOL, anyway, which is probably why it hasn't
been changed in so long.)
Thanks for the help,
Theo Markettos
> That sounds interesting, do you happen to know if they're in C or
> assembler? I'd have thought that perhaps they'd have to be assembler for
> raw speed.
'nwfpe' is the magic Google-phrase. It's mostly in C with a few bits of
inline assembler. Available under the GPL.
Theo
Simon Willcocks
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
Thanks, that looks promising.