Loading ...
Sorry, an error occurred while loading the content.
 

Re: Eiffel compiled as DLL [was Re: "Bug" ..]

Expand Messages
  • Alain Le Guennec
    Hi Geoff, ... Well, I haven t had enough time so far to write a complete HOWTO to explain the process of building DLLs from Eiffel code with SmallEiffel. This
    Message 1 of 8 , Mar 1, 2000
      Hi Geoff,

      Geoff Eldridge <geldridg@...> writes:

      > On 18 Feb 2000, Alain Le Guennec wrote:
      >
      > [ -- 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).

      Well, I haven't had enough time so far to write a complete HOWTO to explain
      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:
      http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
      http://www.geocities.com/Tokyo/Towers/6162/gcc.html
      http://www.geocities.com/Tokyo/Towers/6162/win32/index.html

      Hope this helps.
      Regards,

      --
      Alain Le Guennec, not speaking for IRISA.
    • jacob@jacob.remcomp.fr
      ... under lcc-win32 you pass this file (the .def file) to the linker. ... Under lcc-win32 you say: lcclnk -dll -o mydll.dll myobj.obj anotherobj.obj
      Message 2 of 8 , Mar 1, 2000
        > 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

        under lcc-win32 you pass this file (the .def file) to the linker.

        >
        > Then you can build the DLL itself using the tool 'dllwrap':
        > dllwrap --target i386-mingw32 -mno-cygwin --def exportfile.def -o mydll.dll *.o
        >

        Under lcc-win32 you say:
        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
        statically)

        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 48.23.51.44
        93430 Villetaneuse Fax 01 48.23.95.39
        France
      • Pascal Poncin
        ... I ve been doing some dynamic DLL loading using LoadLibrary and GetProcAdress The use of the latter function brings loss of performance, because it does
        Message 3 of 8 , Mar 1, 2000
          > 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?
          >
          I've been doing some dynamic DLL loading using
          "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).
        Your message has been successfully submitted and would be delivered to recipients shortly.