DeskLib and GCC 4.7.4
Pages: 1 2
Dave Higton (1515) 3409 posts |
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! |
Dave Higton (1515) 3409 posts |
A little experimentation has shown that:
doesn’t work, but:
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. |
David Pitt (102) 743 posts |
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 It did work in the end. |
Theo Markettos (89) 919 posts |
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. |
Dave Higton (1515) 3409 posts |
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:
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:
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. |
Theo Markettos (89) 919 posts |
The standard linking format is that the library should be called libDeskLib/a and the linker line should be: (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: |
David Pitt (102) 743 posts |
There are two builds of DeskLib, SCL and ELF.
The SCL library for the ELF based For an ELF build the library should be 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 :- |
Dave Higton (1515) 3409 posts |
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? |
David Pitt (102) 743 posts |
That is the one to link against to build an ELF, except that the filename should be Added To build an Absolute link to
That goes in 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 |
Theo Markettos (89) 919 posts |
…and the ELF can be converted to Absolute with elf2aif, assuming you compiled with |
Dave Higton (1515) 3409 posts |
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:
Now to see if I can get any of my own code to build! |
David Pitt (102) 743 posts |
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 |
Dave Higton (1515) 3409 posts |
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” |
David Pitt (102) 743 posts |
I get this problem when using the PackMan supplied ELF A peak inside the PackMan supplied |
Dave Higton (1515) 3409 posts |
re. the -fpu= switch: I should add that the list of choices was long enough to astonish me. |
Dave Higton (1515) 3409 posts |
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. |
Dave Higton (1515) 3409 posts |
I’ve now been through all the options for the “-fpu=” switch without success, so I’m stumped again. |
David Pitt (102) 743 posts |
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. |
Dave Higton (1515) 3409 posts |
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. |
Dave Higton (1515) 3409 posts |
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. |
Dave Higton (1515) 3409 posts |
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. |
Rick Murray (539) 13432 posts |
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. |
David Pitt (102) 743 posts |
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: !SharedLibs.lib.abi-2/0.vfp |
Dave Higton (1515) 3409 posts |
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? |
Dave Higton (1515) 3409 posts |
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. |
Pages: 1 2