Maybe a stupid question but I thought I’d asked before I potentially waste a bunch of time. I have code to dynamically load functions using Dynlibs.LoadLibrary, for example:

type
  _Py_Initialize = procedure; cdecl;
  _PyImport_ImportModule = function(module: pchar): PPyObject; cdecl;
var
  […]
  Py_Initialize := _Py_Initialize(GetProcAddress(handle, 'Py_Initialize'));

The problem is I would like to change this to static linking now but I only have function pointers instead of declarations. Is there a way I can get the compiler to statically link these function pointers or do I need to manually change them all by hand to be things like:

	function  PyImport_ImportModule(module: pchar): PPyObject; cdecl;

Regards,
Ryan Joseph

You need to manually change them.

if you look in the packages, you'll see that many library import units exist in 2 flavours. One static, one dynamic.

Michael.

That’s what I was afraid of.

btw, I why does ObjFPC mode not allow this but Delphi mode does? GetProcAddress returns a pointer and I get a type error which can’t be solved because the type of Py_Initialize is anonymous, i.e. there is no formal declaration. Is there a way to cast around this in ObjFPC mode? It would be lots of extra work to add the extra types in because the original code was Delphi.

var
    Py_Initialize: procedure; cdecl;
begin
    Py_Initialize := GetProcAddress(handle, 'Py_Initialize');

Regards,
Ryan Joseph

The FPC modes are simply more stricter, more like the original Pascal in that case. After all a Pointer is not simply a procedure variable.

For your case you can solve it like this:

=== code begin ===

CodePointer(Py_Initialize) := GetProcAddress(handle, 'Py_Initialize');

=== code end ===

Regards,
Sven

On Oct 26, 2019, at 4:26 AM, Sven Barth via fpc-pascal wrote: CodePointer(Py_Initialize) := GetProcAddress(handle, 'Py_Initialize');

Thanks that works.

I don’t think I’ve ever cast a left side value before in Pascal and honestly I didn’t think it was even possible. In fact didn’t we just have a big talk about for loop iterators and how they can’t be type cast? I thought that was because casting the left side value was illegal. Very confused now. ;)

Regards,
Ryan Joseph

The for-in loop works *because* casting the left side of an assignment is legal. If it wouldn't be legal there wouldn't have been any discussion, because then the bug wouldn't be there. The compiler simply transforms

=== code begin ===

for x in y do begin
   // ...
end;

=== code end ===

into

=== code begin ===

tmpenum := y.GetEnumerator;
while tmpenum.MoveNext do begin
   x := tmpenum.Current;
   // ...
end;

=== code end ===

Thus "for cast(x) in y" simply becomes the ordinary assignment "cast(x)
:= tmpenum.Current", which is why the compiler does not complain currently.

However a for-loop does not have an assignment in the usual sense for the loop-variable, thus the following is not legal:

=== code begin ===

var
   i: smallint;
begin
   for word(i) := 0 to 15 do ;
end.

=== code end ===

Regards,
Sven

Ok, I understand how you guys are seeing this now. I wasn’t thinking of it as a while loop so casting just made sense to me from an efficiency standpoint.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Sa., 26. Okt. 2019, 22:46:

As said in the other thread, use absolute to avoid the explicit cast.

Regards,
Sven