[fpc-devel] CThreads.pp

[Ewald]

Once upon a time, on 11/16/2012 07:21 PM to be precise, Jonas Maebe said:
> On 16 Nov 2012, at 19:15, Ewald wrote:
>
>> Well, the compiler gives this error:
>> `Incompatible types: got 
>>     "<address of function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var Pointer):^untyped;Register>" expected
>>     "<procedure variable type of function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var TThreadID):^TThreadRec;Register>"
>>
>> Rather weird, no? Have I missed something? Or is this due to the fact that I declare my threadmanager record using a typed constant?
> In what syntax mode are you compiling? Keep in mind that turning a procedure/function into a procvar is different in FPC/ObjFPC and TP/Delphi modes (with/out the @).
{$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
doesn't solve the problem. The thing that is weird about this is that
the type I use for `TThreadID` is not self defined, it comes from one of
the units used; which somehow is different from some other type that the
TThreadManager record uses. Is there a way to figure out from where fpc
gets a certain symbol via command line switch or something?



>> No, it's definetly sem_open, the litteral error is:
>>     `Error: Identifier not found "sem_open"`
>>
>> My uses list contains the exact same units as in CThreads.pp, in the same order, so I don't see why the symbol isn't found. Also, the entire load of $idfdef's are also copied into my source code.
> The sem_open declaration is included in cthreads via rtl/darwin/pthread.inc (I know it's not actually a pthreads function, but that was the most logical place to put it)
Copying the relevant code that is contained in `rtl/darwin/pthread.inc`
over to  my code seems to fix this issue, logically. I seem to have
missed the `{$i pthread.inc}` line of the original CThreads.pp. Now, as
you said, it isn't really a pthread function, but why not putting it in
pthreads.pp? (thus copy the line {$i pthread.inc} over to pthreads.pp)

As I see it now, programmers don't have access to the symbols contained
in the include file, unless they implement them themselves.

-- 
Ewald