On 25 Sep 2001, at 18:38, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 25 Sep 2001, at 11:08, Frank Heckenbach wrote: [...]
gpc -shared -o libmylib.so mylib.pas
Strange - my Windows versions of GPC (both Mingw and Cygwin) do not understand '-shared' - but GCC seems to recognise it.
I don't know how it was built -- ISTR there are some patches used, and perhaps they disable `-shared' (but why?).
Not sure. I have to look into it.
Anyway, it shouldn't be a big issue, you can compile with GPC and link with GCC, something like:
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.
The inclusion of the RTS in the DLL raises two other related issues; a. trying (with GPC) to link a program that uses the DLL to the '.a' import library results in errors about multiple definitions of some routines that are in 'libgpc.a'. This library gets linked automatically to all GPC programs - but if the whole RTS is already in the DLL, then we have this problem. Is there a switch that we can pass to GPC to tell it not to link 'libgpc.a'? If not, can we add one?
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'?
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/