On 13 apr, 22:24, Marco van de Voort <mar...@[EMAIL PROTECTED]
> wrote:
> On 2008-04-13, P.A.C.Nunn...@[EMAIL PROTECTED]
<P.A.C.Nunn...@[EMAIL PROTECTED]
> wrote:
>
> > Free Pascal Compiler version 2.0.2 [2005/11/17] for
>
> Note that this version is pretty old. 2.2.0 is the most recent version.
>
> > Target OS: FreeBSD/ELF for i386
>
> Also noted.
>
> > Compiling
> > curlobj.pas
> > ocurlprv.inc(112,17) Error: Identifier not found "pIOFile"
> > ocurlprv.inc(112,24) Error: Error in type definition
> > ocurlprt.inc(160,44) Error: Identifier not found "pIOFile"
> > ocurlpub.inc(80,33) Error: Identifier not found "pIOFile"
> > curlobj.pas(74,3) Fatal: There were 4 errors compiling module,
stopping
> > curlobj.pas(74,3) Fatal: Compilation aborted
> > gmake[1]: Leaving directory
`/usr/home/u204056/curl/curlpas-2005-11-05/
> > src'
>
> These are a problem, since the functions that use these types (FILE * in
C)
> are more part of the C runtime of libc (rather than the OS interface).
There
> is no ready to use substitute in the FPC rtl. One can also see in this
> example why we don't sup****t the libc unit. If you look up the relevant
> declarations in libc unit, they reveals too much detail (you can see
glibc
> specific fields in these declarations that will never work with non
glibc's,
> and have some version risk associated for glibc itself even)
>
> If I had to solve this, I would try one of these solutions, in this
order
> (first one first), or a combination.
>
> 1. Try to rewrite it so that I don't need getc and similar C functions.
> 2. Try to see if it is used as an opague pointer (a handle so to speak),
and
> just define it as "pointer".
> 3. Try to copy the needed functions from libc.pp and adapt them with OS
> specific defines.
>
> Personally I think that 3 will work always, but will require adaptation
> every so often, and for each new OS (and mixing with Pascal IO might
break),
> which is why we don't expose these functions by default.
>
> Note that if you can't avoid this all together (iow if FILE is part of
the
> curl library interface), that indicates that libCurl is not really
designed
> as a library with a well defined API, but a binary they quickly tried to
> transform to a lib. If you notice that, file a bug with them. It won't
> solve your problems, but at least they'll rethink it, helping the next
poor
> guy that tries it.
Oops, rewriting it. Yeah, well I guess that will take a better
programmer than I am, although I am going to attempt it. Come to think
of it, all that I require is an FTP function for my program. Isn't
there a comaprable library that might accomplish that?
|
