Shared images, was: Re: OS/2 DLL's

Mon, 14 Oct 96 13:21:09 CST

On Sun, 13 Oct 1996 11:06:07 +0100 (MET), 
Peter Gerwinski   wrote:

>> After some experimenting, I produced an OS/2 dynamic link library (DLL)
>> with GNU Pascal that I could call from another application. Perhaps this
>> is common knowledge but I do not see it documented anywhere.
>
>Thank you.  I didn't know this either.
>
>I planned to implement Borland's style of creating 
>DLLs into GPC.  So with EMX, GPC will have to create
>a correct .def file as well.
>
>Probably somebody here knows how to compile a shared
>library for Linux or other UNIXes with GPC?
>

Shared libraries are very platform dependant.

1) Win32 and OS/2 have the .def files, and need seperate import libraries 
to link an app to a shared image (.dll)

2) ELF unices don't have all of the above, you just use

     gcc -shared -o libfoo.so.X.Y your_obj_files_here

to build a shared image. ELF shared images export everything so no .def is 
needed. If you have a 'libfoo.so.X.Y' shared image, you link it simply with 
-lfoo. Several very nifty features exist, to help object oriented 
languages, to execute initialization code when a shared image is loaded and 
finalized (unloaded). Look at the sources of the Objective C base library 
if you want to know more.

3) Some COFF or A.OUT systems (BSD, older Linux flavours) can use shared 
images too, but at least Linux needed special tools to do so.


The Win32 dll's must be `pure' (no global vars), but this restriction 
doesn't exist for ELF unix.

I think you should just leave the DLL stuff as it is, enforcing a Borland 
PC standard would cripple the possibilities of the ELF for instance.

The winapi-0.1.2.tar.gz archive in the GNU archives has a few smart `sed'
scripts to generate .def files from a DLL. For cygwin32, the dlltool.exe
program can build the import libraries.


I have done some attempts to build the GNU Pascal RTS (libgpc.a) as a 
shared library. For ELF unix, this a very easy. A `hello world' program is 
reduced to 2K. For win32, several global variables ('input', 'output', 
gpc_argv and more) make this impossible.

I have some plans to rework the RTS, split it in 'ISO', 'ISO extended' and 
add 'Borland System.tpu' to it. Purify the code. Add documentation 
fragments to the code, so a `chew' program can generate a rts.texi 
documentation file. Someday...

Just my HFL 0.02,

JanJaap


---
"Nothing shocks me, I'm a scientist", Indiana Jones

J.J. van der Heijden (j.j.vanderheijden@student.utwente.nl)