DeskLib and GCC 4.7.4

Has anybody got a DeskLib project to build with GCC 4.7.4?

I’ve installed DeskLib and GCC via Packman, into the default paths that Packman offered. No project that I’ve tried, including the DeskLib examples that I also installed with Packman, build – they can’t find the .h files using the DeskLib:WimpSWIs.h path normally used in #include statements.

I’m very susprised to see DeskLib’s directory structure. There is an Apps.Library directory, in wwhich are !DeskLib, !DLUser and a DeskLib folder. Within the Desklib folder is another !Desklib, plus the Examples directory. So two different !DeskLib at different levels is worrying.

Within the higher level !DeskLib is an include directory; within that are the header files, all with a suffix “/h”.

Within the lowere level !DeskLib is an include directory, within which is an h directory, within which are all the same header files, without any suffix.

But neither set of include files is found when GCC tries to compile anything.

Help welcome!

A little experimentation has shown that:

#include "DeskLib:WimpSWIs.h"

doesn’t work, but:

#include "DeskLib:WimpSWIs/h"

finds the file. (It still fails immediately afterwards, of course, because WimpSWIs.h includes DeskLib:Core.h)

So either there is a problem in (lack of) translation between naming conventions, or the DeskLib$Path variable doesn’t contain the correct path to the files with RISC OS naming convention. I get confused too easily, but it looks to me like DeskLib$Path does contain the correct path.

Has anybody got a DeskLib project to build with GCC 4.7.4?

Yes, but there were complications to be resolved first, one of which was includes filenames not in RISC OS format. As I recall there were a number of DeskLib versions out there.

This from css.programmer may help, the DeskLib bit is some way down that.

I recall altering to files from header/h to h.header and there was a conflict between two different h.time headers.

It did work in the end.

The csa.programmer thread is worth reading. Unfortunately I haven’t had time to make any further progress on sorting out the versions since then.

Thanks to both of you for your help.

More progress: I got the compilation steps to work. I think there may be simply a problem with the packaging installation paths; there is a $.Apps.Library.!DeskLib and another one one level down at $.Apps.Library.DeskLib.!DeskLib I copied (at least part of) the lower level include directory into the higher level one, whereupon all the include files referred to by e.g. “WimpSWIs.h” were found because the file h.WimpSWIs exists in the right place. Theo, if you agree that the packaging path is the issue and you’re of a mind to fix it, I’m happy to go through (possibly numerous) reinstallations of !DeskLib to verify correct operation.

I’ve now moved forward to a linking problem. I’m lost here because I simply don’t know what is expected. There have to be files, of the correct formats, in the correct places, and the invocation of the linker has to be correct. I can’t be confident that any is correct.

The error message I have is:

/DeskLib_Core:o/DeskLib: file not recognized: File format not recognized

This is referring to a file $.Apps.Library.!DeskLib.o.Desklib (if I rename it, the file is not found). The file is of type Text but its content is binary – the first 4 bytes are C5 C6 CB C3.

The invocation line is:

gccbin:gcc -mlibscl -mthrowback -o !RunImage TestApp.o DeskLib_Core:o.DeskLib DeskLib_Core:o.Debug.pipetype DeskLib_Core:o.Debug.signal

which of course is built from several fragments in the makefile.

The csap thread is not much help for this problem. I see references to “libDeskLib/a” but should that be in the makefile or the name of the file within !DeskLib? With the locations of the header files, I had some idea of what I was doing, but ELF binaries and the relevant libraries are new and unfamiliar to me, so I have to rely on your help. When it comes to testing a solution for distribution, though, I’m able and willing to do so and thus repay the help you’re giving me.

The standard linking format is that the library should be called libDeskLib/a and the linker line should be:
gcc -lDeskLib -LDeskLib:

(or for instance DeskLib:lib if it’s in there)

I don’t know what the o.Desklib file is, but you don’t want to link that: the library should be linked into an archive (a file with a “/a” extension).

I don’t know the provenance of the Desklib you’re using, it may be one intended for Norcroft. It would make sense to try the most recent build from here:
http://ci.riscos.info/job/packages/job/desklib/
so we’re on the same page.

There are two builds of DeskLib, SCL and ELF.

The SCL library is o.DeskLib Error That is for the DDE

The SCL library for the ELF based !GCC is libDesk-scl/a

For an ELF build the library should be libDeskLib/a, as I recall the ‘lib’ prefix was missing from the build. The entry in any command however is plain ‘DeskLib", the linker seems to know to add the ’lib’ prefix and '/a' suffix.

I gave up on the application wrappers, the extra DeskLib within the directory hierarchy rings a bell. Here DeskLib is in a plain directory with an Obey files that sets up the required Path.

UnSet DeskLib*
Set DeskLib$Dir <Obey$Dir>
Set DeskLib$Path <DeskLib$Dir>.include.,<DeskLib$Dir>.lib.

HTH.

P.S. The versions in use here, downloaded some months ago, were from :-

http://ci.riscos.info/job/packages/job/desklib/

http://ci.riscos.info/job/packages/job/desklib-scl

There is a file !DeskLib.DeskLib/a whose content begins with !<arch>

There is a file !DeskLib.libDesk/so whose content begins with 0×7f ELF which I guess must be an ELF library.

Is one of them what I’m trying to link against?

There is a file !DeskLib.DeskLib/a whose content begins with !

That is the one to link against to build an ELF, except that the filename should be !DeskLib.libDeskLib/a

Added To build an Absolute link to libDesk-scl/a

There is a file !DeskLib.libDesk/so whose content begins with 0×7f ELF which I guess must be an ELF library.

That goes in !SharedLibs.lib

P.S.

Two command lines, one builds an ELF the other an Absolute.

*gcc task.c -IDeskLib:  -LDeskLib: -lDeskLib -o !RunImage

*gcc task.c -mlibscl -IDeskLib:  -LDeskLib: -lDesk-scl -o !RunImage

…and the ELF can be converted to Absolute with elf2aif, assuming you compiled with -static

Many thanks, I now have a working !TestApp from the DeskLib examples.

I’ve been (virtually!) tearing my hair out for a while wondering how to fix the discrepancies between hard and soft FP, but it turned out to be that TestApp.o was out of date. That’s a missing feature of make – anything that’s built depends on the makefile, but, if you modify the makefile, the object files don’t get rebuilt. Or so it seems. Anyway…

Another thing I had to do was remove calls to Sound_SysBeep() from the source code, as each call caused an undefined reference error.

So let’s try to gather together the changes that were necessary:

• Installing DeskLib using PackMan seems to put one of the parts of DeskLib in an incorrect location. (I wish the documentation, both of DeskLib’s help files and the brief comments in Packman’s list, would make it clearer what is necessary to install.)

• DeskLib/a must be renamed to libDeskLib/a

• libDesk/so must be installed in !SharedLibs.lib

• DeskLib.Examples.!TestApp.Makefile should have its LIBS definition removed.

• DeskLib.examples.!TestApp.Makefile should have the LINKFLAGS definition changed. This definition worked for me:

LINKFLAGS = -mthrowback -IDeskLib: -LDeskLib: -lDeskLib

• I haven’t looked at why the Sound_SysBeep() calls aren’t defined, but they need to be removed before !TestApp will build – or the problem otherwise fixed.

Now to see if I can get any of my own code to build!

By way of icing on the cake there is the UnixLib issue to be had on the Raspberry Pi Mk3 when building with the current DeskLib 3.00 downloads. (The DeskLib 3.00 version is defined in h.core). DeskLib builds from the autobuilder fix that, as very briefly tested.

What -fpu= switch do I need to give to asasm to agree with the default (soft FP) setting of gcc? -fpu=SoftFPA doesn’t seem to satisfy it. I see the error “md5bits.o uses hardware FP, whereas !RunImage uses software FP”

I haven’t looked at why the Sound_SysBeep() calls aren’t defined, but they need to be removed before !TestApp will build – or the problem otherwise fixed.

I get this problem when using the PackMan supplied ELF !DeskLib, I didn’t when using the later ELF DeskLib previously downloaded from http://ci.riscos.info/job/packages/job/desklib/

A peak inside the PackMan supplied libDeskLib/a showed the SysBeep to be Environment_SysBeep. The later ELF DeskLib has its headers amended to redirect Sound_SysBeep to Environment_SysBeep. The PackMan supplied ELF DeskLib has a mismatch between its headers and library.

re. the -fpu= switch: I should add that the list of choices was long enough to astonish me.

Another couple of oddities: I’m getting undefined references to OS_ReadVarVal and OS_CLI from my main.c which includes KernelSWIs.h. In KernelSWIs.h, OS_ReadVarVal is preceded by the “extern” keyword, which seems odd. OS_CLI is there. Do these two errors show simply that the DeskLib distro has been incorrectly or incompletely built?

I’ve started working through the roughly 50 options for the -fpu= switch in turn so I can find one that makes linking work. I know of no other way. I have to say, though, that I don’t understand why the error is generated; I can’t see any FP operations within md5bits.s.

I’ve now been through all the options for the “-fpu=” switch without success, so I’m stumped again.

Another couple of oddities: I’m getting undefined references to OS_ReadVarVal and OS_CLI from my main.c which includes KernelSWIs.h. In KernelSWIs.h, OS_ReadVarVal is preceded by the “extern” keyword, which seems odd. OS_CLI is there. Do these two errors show simply that the DeskLib distro has been incorrectly or incompletely built?

That was my thinking in my previous answer above on SysBeep. In the PackMan DeskLib changes involving moving functions into Environment had been implemented in the library but not in the headers!

I am now using a locally built ELF DeskLib, which will be very similar to the recent builds Theo referred to above, the significant change being RPi3 compatibility..

h.KernelSWIs contains this comment :-

28 Sep 2007 Removed GSTrans, ReadVarVal, ReadModeVariable to Environment module

h.Environment has this :-

/* Old name defined to maintain backwards compatibilty */
#define OS_ReadVarVal(v,b,n) Environment_SysVarRead(v,b,n)
/* haddoc ignore off */
BOOL Environment_SysVarRead(const char *varname, char *buf, int bufsize);
/*
  This reads the value of the system variable whose name is 'varname',
  placing the text in the buffer 'buf' of size 'bufsize'. It returns
  true is the variable exists and false otherwise.

  If bufsize is 0 then only the presence of the variable will be tested
  and the buffer will not be altered.
*/

I can run tests here if that would help.

I did begin to suspect a few hours ago that there should be an Environment.h header file, but there isn’t in the distro.

Correction: there is an Environment/h but not h.Environment. Copying the file over to the h directory, and adding the #include directive, has fixed the problem.

The one problem left is that of conflicting FP requirements. I wish I understood it.

Having altered the Makefile so that both compilation and linking use the “-mfpu=vfp” switch, I now see a sheaf of error messages stating the various DeskLib functions use FPA instructions.

Trial and error. Sadly the amount of error exactly equals the amount of trial.

Having altered the Makefile so that both compilation and linking use the “-mfpu=vfp” switch, I now see a sheaf of error messages stating the various DeskLib functions use FPA instructions.

I don’t use GCC, but I think the protocol/area/calling convention needs to match up. VFP != FPA.

Therefore, this ought to leave you with two choices:

1. Rebuild DeskLib to use VFP instructions (hmm, I can’t offhand think of much FP use within DeskLib, so this might be a block setting rather than indicating of what’s going in within DeskLib).

2. Alter your MakeFile to build using FPA.

The latter will be simpler, though you’ll get a penalty if your own program makes a lot of use of floats.

The one problem left is that of conflicting FP requirements. I wish I understood it.

Let’s be clear at the outset, I don’t understand it either.

This from GCC’s Help might be the problem.

1.3.4.3. VFP – Third party libraries

At build time, it is up to the programmer to ensure that the correct library (ie, VFP enabled) is referenced at link time via the -L and -l options. At runtime any VFP enabled versions should be installed in:

Compiling and linking with the switch “-mfpu=fpa” removes all but one of the errors, so it presumably means that everything except md5bits is using FPA. (I doubt that there is an FP instruction anywhere in my source code.) I just seem to be unable to influence md5bits.o to use anything other than hardware FP, according to the error message.

I don’t suppose there is any application anywhere that will textify an ELF file?

My reason for using asasm is that the source file was written for an earlier assembler, and gas seems to complain about pretty much every non-blank source line, which (along with the lack of documentation that I know of) made the prospect of translating the source for gas look daunting.