Having stumbled over this problem last year, I now have a very simple
rule (and which seems to work).
If you are linking with an external static library (e.g. libssl.a) then
you omit the external library name on each function call, but must
include a $LINKLIB e.g. ($LINKLIB ssl.a}.
If you are linking with an external shared library (e.g.
libssl-3-x64.dll) then you must explicitly provide the external library
name on each function call so that the loader knows which library to
look in. Note. No $LINKLIB directive.
On 05/01/2025 11:49, Hairy Pixels via fpc-pascal wrote:
On Jan 5, 2025 at 6:45:49 PM, Tomas Hajny <xhaj...@hajny.biz> wrote:
As you might have noticed, it's simply a more general solution allowing
to cover all target platforms supporting dynamic libraries in a more or
less equal way.
Yeah if DLLs have their own namepace and $LINKLIB doesn’t propagate to
all external functions in the unit then I guess the functions won’t
link when a DLL is used.
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
