Prof. A Olowofoyeku (The African Chief) wrote:
On 25 Sep 2001, at 18:38, Frank Heckenbach wrote:
gpc -c mylib.pas gcc -shared -o libmylib.so mylib.o -lgpc -lm
Yes, that works to produce a Windows DLL (which also includes all routines in libgpc.a). This seems to be a reasonable way of packing the whole GPC RTS as a DLL. This can be very useful for some purposes (e.g., smaller executables?), but if you want a DLL containing only your own functions and not the whole RTS, then this is not the way to do it.
I think in this case one should first put a RTS in a dynamic library of it own, and then your own units into another one. The latter linking as well as the final linking of the program will both link to the dynamic RTS, so there should be now conflicts.
If libgpc.so is installed in the same directory as libgpc.a, the linker should prefer the dynamic one automatically, unless given `-static' (at least on Unix).
b. trying to link the program with gcc instead of GPC causes an 'undefined reference' error ('_p_initialize' is undefined). On the other hand, '_p_finalize' is in the DLL. Is there any reason to have one and not both of them in 'libgpc.a'?
Hmm, in my version they're both there:
# objdump --syms `gpc --print-file-name=libgpc.a` | grep -w -e _p_initialize -e _p_finalize 000017b0 g F .text 00000034 _p_finalize 00000c78 g F .text 0000003b _p_initialize
Frank