Linking OSLib Support

[John Tytgat]

In message <K+JrHDAvYcS6EwCB at mk-net.demon.co.uk>
          Tony van der Hoff <OSLib at mk-net.demon.co.uk> wrote:

> Not entirely correct, I'm afraid, John.
> 
> As I said above (did you read it? :-),

Yes :-)

> there is a problem with signal.h
> in each of the libraries being incompatible, which is why the X module
> presently fails to link.

There are a lot of other things which are not *binary* compatible (mind
the word 'binary').

> I believe I can fix that. For now I have just
> removed the dependency between it and the Event module. AFAIK, every
> other module links correctly.
> 
> I am presently using the (621 beta) OSLibSupport binary (built with clib
> headers) together with UNIXLib without any problems.

I see this as a timebomb ticking.  It is not because you can link
OSLibSupport compiled with CLib headers and finally linked with UnixLib,
that this will work.  I can assure you that the makers of UnixLib never
anticipated this kind of senario and that this is not garanteed to
work now or in the future.  You really have to use the correct headers
of the runtime library you are using to link with.

> As I understand it,
> Simon's problem is now also resolved. There is no need to recompile,
> providing X is not used.

You might be really lucky and get away with it now but I advise people not
to take the risk and to recompile OSLibSupport with the headers belonging
to the runtime library they will use in their final target.

E.g. when you realise that FILE from <stdio.h> in CLib is declared as :

> typedef struct __FILE_struct
> { unsigned char *__ptr;
>   int __icnt;      /* two separate _cnt fields so we can police ...        */
>   int __ocnt;      /* ... restrictions that read/write are fseek separated */
>   int __flag;
>   /* AM: the following things do NOT need __ prefixes as they are          */
>   /* are invisible in an ANSI-conforming program.                          */
>   unsigned char *__base; /* buffer base */
>   int __file;            /* RISCOS/Arthur/Brazil file handle */
>   long __pos;            /* position in file */
>   int __bufsiz;          /* maximum buffer size */
>   int __signature;       /* used with temporary files */
>   struct __extradata *__extrap; /* pointer to information about stream */
> } FILE;

with feof() defined as :

> #define feof(stream) ((stream)->__flag & _IOEOF)

and FILE from <stdio.h> in UnixLib is declared as :

> typedef struct __iobuf FILE;
> 
> struct __iobuf
> {
>   unsigned int __magic;  /* Magic number for stream validation.  */
>   unsigned char *i_ptr;
>   unsigned char *i_base;
>   int i_cnt;
>   unsigned char *o_ptr;
>   unsigned char *o_base;
>   int o_cnt;
>   size_t __bufsize; /* size of buffer.  */
>   fpos_t __offset; /* current file position of underlying file descr. */
>   __io_mode __mode; /* file access mode */
>   unsigned char __pushedchar; /* character that has been pushed back */
>   int __pushedi_cnt; /* position of i_cnt before char was pushed back */
>   unsigned int __pushedback:1; /* ungetc has pushed back a character */
>   unsigned int __eof:1; /* end of file encountered */
>   unsigned int __error:1; /* error encountered */
>   unsigned int __iuserbuf:1; /* buffer from user (should not be freed) */
>   unsigned int __ouserbuf:1; /* buffer from user (should not be freed) */
>   unsigned int __linebuf:1; /* flush on newline */
>   unsigned int __ispipe:1; /* nonzero if opened by popen */
>   unsigned int __string_istream:1; /* nonzero if string input stream */
>   int fd; /* File descriptor.  */
>   FILE *next; /* next FILE in the linked list */
> };

with feof() defined as :

> #define feof(stream) ((stream)->__eof != 0)

You clearly can see that they are not binary compatible.  As I said
before, you might be very lucky and get away with a tiny library
like OSLibSupport but it is a timebomb ticking... <run & hide> ;-)

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