Hello ,
We tried compiling a DLL with the following sources but have not been successful.
program mycall; function add(x:integer;y:integer):integer; far; external 'mylib'; var b:integer; begin b:=add(5,6); end.
-------------------------------------------- library mylib; uses winprocs; function add(x:integer;y:integer):integer;export; begin add:=x+y; end; exports add index 1; begin end. -------------------------------------------------
What changes do we have to make to the sources to build the DLL?
Regards, Anuradha
Frank Heckenbach wrote:
HARIKRISHNA Kocheralkota wrote:
Is there any GPC compiler option available for creating .so
The same as with GCC, e.g.:
gpc -shared -Wl,-soname=whatever -o foo.so.42 files
You might also want to try libtool (but I have no experience with it myself).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
-- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123
ANURADHA Srinivasan wrote:
We tried compiling a DLL with the following sources but have not been successful.
program mycall; function add(x:integer;y:integer):integer; far; external 'mylib'; var b:integer; begin b:=add(5,6); end.
library mylib; uses winprocs; function add(x:integer;y:integer):integer;export; begin add:=x+y; end; exports add index 1; begin end.
What changes do we have to make to the sources to build the DLL?
unit mylib;
interface
{ Commented out because I don't have such a unit, but should work the same with it. uses winprocs; }
function add(x:integer;y:integer):integer;
implementation
function add(x:integer;y:integer):integer; begin add:=x+y; end;
begin end.
gpc -shared -o libmylib.so mylib.pas
(Install libmylib.so in a standard lib directory, or set LD_LIBRARY_PATH.)
program mycall; {$L mylib} function add(x:integer;y:integer):integer; external; var b:integer; begin b:=add(5,6); writeln(b) end.
Frank
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.
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/
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?).
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
Frank
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/
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
On 27 Sep 01, at 5:02, Frank Heckenbach wrote:
[...]
I think in this case one should first put a RTS in a dynamic library of it own,
How do you do that? I would love to simply convert the libgpc.a archive itself. I have tried various things with 'ld' and 'gcc', but I have not been successful.
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
Yes, they are both in mine as well - but for some reason, '_p_initialize' doesn't make it into the DLL. It is weird, because everything else is there! Any ideas?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 27 Sep 01, at 5:02, Frank Heckenbach wrote:
[...]
I think in this case one should first put a RTS in a dynamic library of it own,
How do you do that? I would love to simply convert the libgpc.a archive itself. I have tried various things with 'ld' and 'gcc', but I have not been successful.
The RTS Makefile contains rules for building a dynamic library, but they're not yet "officially supported". You can try `WITH_SHARED=yes' on the make command line.
# objdump --syms `gpc --print-file-name=libgpc.a` | grep -w -e # _p_initialize -e _p_finalize
Yes, they are both in mine as well - but for some reason, '_p_initialize' doesn't make it into the DLL. It is weird, because everything else is there! Any ideas?
Not really.
Frank
On 24 Sep 2001, at 15:46, ANURADHA Srinivasan wrote:
Hello ,
We tried compiling a DLL with the following sources but have not been successful.
program mycall; function add(x:integer;y:integer):integer; far; external 'mylib';
[...] That is Delphi syntax. Doesn't work with GPC.
library mylib;
[...] GPC doesn't understand "library".
uses winprocs; function add(x:integer;y:integer):integer;export; begin add:=x+y; end; exports add index 1; begin end.
What changes do we have to make to the sources to build the DLL?
Building a DLL with GNU tools is not for the fainthearted. Mumit Khan explains all the magical rites at: http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html
I have an application (a front end to GPC that uses .cfg files like Delphi and Borland Pascal) in which I have tried to make provision for building DLLs with a simple switch ('--dll'). This works somewhat and succeeds in producing a DLL, and a '.a' library containing the DLL exports. However, it has been a pain to get GPC to successfully link to this '.a' file with 'external' and 'asmname' declarations. GPC can load the DLL routines using 'LoadLibrary', as long as the DLL functions are not compiled with the 'Stdcall' attribute. This of course means that only GPC can use the DLL (not good). On the other hand, Delphi can load the DLL routines using 'LoadLibrary' if the functions are compiled with the 'Stdcall' attribute - which is the norm for Win32 DLLs; but then GPC can't load the DLL functions successfully, even using 'LoadLibrary'. So something is obviously amiss somewhere (more likely, there is something that I have not understood properly).
Anyway, so far, everything depends on the applications that you intend to use your DLL. My program is LGPLed. The current development version is a bit untidy, but if you want a copy of the sources, you are welcome.
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/
-
ANURADHA Srinivasan -
Frank Heckenbach -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)