[SOLVED] system unit and external functions

[Key-Real]

compiling system unit


wanna do:

Code: Pascal  [Select][+][-]

1. procedure _InitHeap(p: pdword; l: dword); stdcall external 'InitHeap';
2. procedure _free(p: pointer); stdcall external 'free';
3. function _malloc(l: dword): pointer; stdcall external 'malloc';
4. function _printf(const fmt: pchar): longint; varargs; cdecl; external 'printf';
5.  

but:

Code: Pascal  [Select][+][-]

1. Error: Creation of Dynamic/Shared Libraries not supported

ideas?

[Thaddy]

Well, for one the calling conventions make no sense for the compiler you are trying to develop.
Second, although it is perfectly legal to use External on code that is really internal, you still need to implement them as compiler intrinsics.

[Key-Real]

Second, although it is perfectly legal to use External on code that is really internal, you still need to implement them as compiler intrinsics.

Code: Pascal  [Select][+][-]

1. procedure _InitHeap(p: pdword; l: dword); external 'InitHeap'; compilerproc;

?

Or I don't undrstand what you mean

[Thaddy]

You left out the implementation part..?

[Key-Real]

this is in the impementation part

[Key-Real]

You say this is valid to call internal functions out of the system unit.

_everything_ I try leads me to

Error: Creation of Dynamic/Shared Libraries not supported

[rvk]

Error: Creation of Dynamic/Shared Libraries not supported
Creating dynamically loadable libraries is not supported for this platform, because it was not yet implemented in the compiler.

Maybe you can give more information or strip to a compilable example and show the complete source. (With commands how you compile and for what platform)

[Key-Real]

Code: Pascal  [Select][+][-]

1. procedure _InitHeap(p: pdword; l: dword); external name 'InitHeap';
2. procedure _free(p: pointer); external name 'free';
3. function _malloc(l: dword): pointer; external name 'malloc';
4. function _printf(const fmt: pchar): longint; varargs; cdecl; external name 'printf';

this works

[Thaddy]

So it was the calling convention?
That still does not make sense to me.
WHERE is the code implementation?
Do you have a public repository so I can have a look?

[MarkMLl]

So to summarise, the "Remark" section at https://www.freepascal.org/docs-html/current/ref/refse98.html appears to apply: "external" may be followed by a library name or left blank, then followed by "name" to give a named entry point in that library or by "index" to give an indexed entry point in a DLL.

There's limited information on that page about the distinction between static and dynamic libraries. I think I'd reiterate this helpful snippet that somebody provided a few months ago:

Code: Pascal  [Select][+][-]

1. In a nutshell:
2. {$LinkLib LIBNAME} --> you need the LIBNAME.a file
3. {$Link LIBNAME} --> you need the LIBNAME.o file
4.  

There's a bit more at https://www.freepascal.org/docs-html/current/prog/progsu146.html#x185-1880007.1.1 which is relevant.

It appears to be easier to use the PDF variant of the documentation, since it's easier to locate things by a brute-force search.

You seem to be making very heavy going of this, and having much more difficulty than I experienced back when I was looking at the MIPS target. However that was pre-v3, and there might have been sufficient library changes etc. since then to make the job more difficult.

MarkMLl

[MarkMLl]

So it was the calling convention?
That still does not make sense to me.
WHERE is the code implementation?
Do you have a public repository so I can have a look?

Thaddy, can it. He's made it quite clear- this time at least- what the problem was, and I'm sure it's one we've all experienced at various times.

MarkMLl

[Thaddy]

Mark,

A small example why my remark refers to legal code within the compiler itself is the versioning I gave a couple of months ago:

Code: Pascal  [Select][+][-]

1. var
2.   fpcversion:array[0..255] of ansichar; external name '__fpc_ident';

This means the code is actually implemented by the compiler and stored in a data section.
Something similar can also be done in a code section, provided it is actually implemented.

[MarkMLl]

Thaddy, I know. But he now realises what he was doing wrong in the lines he asked about at the start of this specific thread, and has correctly posted his solution and marked it as solved.

Whether he got himself into that position by ignoring (or, more likely, not understanding) your earlier comments is irrelevant, and it's not helpful to dwell on that.

There might possibly be ways that he could put these questions more constructively, e.g. by posting compilable demo/test programs. However since he's doing a non-standard build (i.e. relying heavily on the RTL makefiles etc.) that might not be entirely feasible: it would be interesting to have some comments from one of the core developers in this context.

MarkMLl