New user problems with OSLib

[John Tytgat]

In message <5aa9441650.freenet at beerling.freenet.de>
          Mark Beerling <beerling at freenet.de> wrote:

> Hallo Everyone
> 
> this Christmas holiday I wanted to do something useful so I decided to 
> convert one of my programs from Acorns/Castles C/C++ compiler to the 
> GCC compiler and to use OSLib.
> 
> I downloaded OSLib V6.9 with OSLibSupport and the !Dustbin program as 
> an example. I'm currently using GCC Version 3.4.4 Release 3 under ROS 
> 4.39.

Any reason why you don't use 3.4.6 Release 3 ? Otherwise you seem to
miss 2 years of bug fixes.

> I've managed to change the source of my program so that the program 
> compiles with OSLib & GCC.
> 
> Problem #1
> ==========
> 
> In order to get the program to compile I had to change the header file 
> 'Systypes' in OSLibSupport.h as follows:
> 
> Line 81:
> commented out
> // typedef os_error _kernel_oserror;  // from kernel.h

I'm not so sure commenting out is the best fix.  The actual code around
this is:

> // old _kernel stuff
> #if !defined( _kernel_h )
>  typedef os_error _kernel_oserror;  // from kernel.h
> #endif

So there is a test on _kernel_h.  Oddly enough, the Norcroft kernel.h
files I have seem to use __kernel.h as dbl include guard and the GCCSDK's
libscl kernel.h uses __KERNEL_H.

So this is perhaps better (assuming _kernel_h was once used in the past
as well):

#if !defined( _kernel_h ) && !defined( __kernel_h ) && !defined( __KERNEL_H )

but it feels like a gross hack.

> Line 98:
> changed
>     #include "toolboxtypes.H"
> to
>     #include "toolboxtypes.h"

Sure, will be fixed.  Thanks.

> Problem #2
> ==========
> 
> With my program and the !Dustbin example (using Acorn C) the following 
> link error was produced:
> 
> 
> !RunImage does not yet exist
> Link -aif -c++ -o !RunImage @.o.main @.o.MainWnd @.o.DB C:o.Stubs  
> OSLibSupport:o.OSLibSupport32  OSLib:o.OSLib32
> ARM Linker: (Error) Undefined symbol(s).
> ARM Linker:     event_register_toolbox_handler, referred to from 
> @.o.main.
> ARM Linker:     event_register_message_handler, referred to from 
> @.o.main.
> ARM Linker:     event_initialise, referred to from @.o.main.
> ARM Linker:     event_set_mask, referred to from @.o.main.
> ARM Linker:     event_poll, referred to from @.o.main.
> ARM Linker:     event_deregister_message_handler, referred to from 
> @.o.MainWnd.
> ARM Linker:     event_register_wimp_handler, referred to from 
> @.o.MainWnd.
> ARM Linker:     ___arm_alloca_longjmp, referred to from 
> OSLibSupport:o.OSLibSupport32(o32).
> ARM Linker:     Err_MakeError, referred to from 
> OSLibSupport:o.OSLibSupport32(o32).
> ARM Linker: Errors in link, no output generated.
> ARM Linker: finished,  10 informational, 0 warning and 1 error 
> messages.
> AMU: *** exit (1) ***
> 
> AMU: *** 'all' not re-made because of errors ***
> 
> 
> I examined the contents of the library OSLibSupport (using LibFile -s) 
> and found that the event_* functions required are not in the library.
> They are not in Version 6.80 but are in version 6.70 (APCS-R (26-bit)) 
> which is obsolete. I'm now a bit confused.
> 
> The version 6.90 has the required events_* headers, but the functions 
> are not in the library. Also the library comes in two flavours: 
> OSLibSupport and OSLibSupport32. Is not the library without the '32' 
> extension the version for APCS-R? Why are the event_* functions not in 
> the library.

This was a OSLib 6.80/6.90 release error.  We had at one point an
OSLibSupport released without the Event.o object file.  Tony fixed this
around May 2007 for the 6.90.  Please update your OSLibSupport32 from
<URL:http://sourceforge.net/project/showfiles.php?group_id=51230>.

But note that __arm_alloca_longjump is a GCC generated label by its ARM
backend to deal with alloca calls made before a longjump is used in the
code and that's one of the several gotchas when mixing object files made
with GCC and Acorn C together.  So I would recommend to use only either
GCC or either Acorn C for compiling & linking the complete project.

And when you use GCC, use the gcc driver program to do the linking instead
of calling drlink yourself.  Something like:
gcc -mlibscl -o !RunImage obj1.o obj2.o OSLibSupport:o.OSLibSupport32 OSLib:o.OSLib32

Thanks for the feedback,
John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven