Re: Eiffel compiled as DLL [was Re: "Bug" ..]
- Hi Geoff,
Geoff Eldridge <geldridg@...> writes:
> On 18 Feb 2000, Alain Le Guennec wrote:Well, I haven't had enough time so far to write a complete HOWTO to explain
> [ -- snipped from http://www.egroups.com/group/smalleiffel/1449.html --]
> > We use SmallEiffel for the core of a tool driven by a Java GUI
> > (the Eiffel part is compiled as a DLL), [..]
> This sounds really interesting and it is something I (and guess others)
> have been wondering about (for elj-win32 in my case) for sometime now.
> Is there any chance that you can elaborate on what has been done and how
> it was done? A facility like this would be great for elj-win32 users. I
> know that lcc-win32 can handle dll's (Jacob, please feel free to
> elaborate also).
the process of building DLLs from Eiffel code with SmallEiffel.
This is on my to-do list :)
In a nutshell:
-The program consists of three parts:
-the Java GUI
-the core application written in Eiffel
-some C code to do the glue, using both Java's JNI and Eiffel's Cecil interfaces.
The last two parts are included in the DLL,
and only routines declared in the C glue with the JNI_EXPORT macro
are exported from the DLL (the Eiffel routines exported via Cecil
are kept private to the DLL, and used only from the C glue code).
The Eiffel part is compiled with the -no_main and -cecil options,
and the resulting C files and the C/JNI glue are compiled to .o files.
So far, this is relatively simple
(although converting strings from Java to Eiffel can be a bit tricky :)
The remainging part - building the DLL itself from the .o files -
is a bit more complicated and architecture dependent.
Under UNIX systems such as Linux or Solaris, it is relatively easy
to build a DLL (.so file), using the -fPIC and -shared flags of GCC.
Under Win32, this involves tools distributed with Cygwin32
(or Mingw32 respectively). The instructions to proceed
are very much inspired by the excellent documents provided by Mumit Khan
which can be found at: http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
(BTW, I don't know if this is do-able with lcc-win32.
FYI, we also managed to build the DLL using Microsoft Visual C++ environment,
but so far have preferred using only free software, even under Win32 :)
Under Win32, you first need to build an "export" file
containing declarations of symbols that are to be exported by the DLL.
This can be done using the tool 'dlltool':
dlltool -A -z exportfile.def glue.o
Then you can build the DLL itself using the tool 'dllwrap':
dllwrap --target i386-mingw32 -mno-cygwin --def exportfile.def -o mydll.dll *.o
Note that the process is simplified because the JNI glue takes care
(through the use of the JNI_EXPORT macros) of the calling conventions
needed to call routines that come from a DLL (stdcall under win32).
I think it could be possible to add the stdcall convention
for Eiffel external features and/or Cecil, directly in SmallEiffel,
but I don't know the exact details.
For more information, here are some interesting URLs
I found about this topic of building DLLs with GCC under Win32:
Hope this helps.
Alain Le Guennec, not speaking for IRISA.
> Under Win32, you first need to build an "export" fileunder lcc-win32 you pass this file (the .def file) to the linker.
> containing declarations of symbols that are to be exported by the DLL.
> This can be done using the tool 'dlltool':
> dlltool -A -z exportfile.def glue.o
>Under lcc-win32 you say:
> Then you can build the DLL itself using the tool 'dllwrap':
> dllwrap --target i386-mingw32 -mno-cygwin --def exportfile.def -o mydll.dll *.o
lcclnk -dll -o mydll.dll myobj.obj anotherobj.obj exports.def
The linker will automatically create
mydll.exp (the file with the exports definition)
mydll.lib (the import library to use the dll with other programs linked
Note that the dynamic loader I am building is already able to link dynamically
object files, not only dlls!
The object files will be loaded into the address space of the calling proces,
fixed up, and started if necessary...
To go back to the dlls, I am considering eliminating the exports definitions
and just export all public symbols. This would waste a lot of bytes but in
this days of 128MB RAM machines I do not think that a small import table of
several dozen KiloBytes would make any difference would it?
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel 01 18.104.22.168
93430 Villetaneuse Fax 01 22.214.171.124
> To go back to the dlls, I am considering eliminating the exportsI've been doing some dynamic DLL loading using
> and just export all public symbols. This would waste a lot of bytes but in
> this days of 128MB RAM machines I do not think that a small
> import table of
> several dozen KiloBytes would make any difference would it?
"LoadLibrary" and "GetProcAdress"
The use of the latter function brings loss of performance, because it does a
string search in the DLL export table. Calling a DLL Function by Index is
faster but sometimes "GetProcAdress" is useful. So here one would suffer a
disadvantage (slower calls).