Re: [ooc-compiler] DLL creation with oo2c?

[Frank H. <fh...@ph...>]

Michael van Acken wrote:
> Stewart Greenhill <sgr...@ii...> writes:
> 
> 
>>Hi Frank,
>>
>>
>>>2 reasons why it would be nice to generate DLLs with oo2c:
>>>
>>>- Using oberon in larger projects even when others use other languages
>>>- Using oberon when the main program has to be in another language,
>>>e.g. when it is created by a tool.
>>
>>Agreed.
>>
>>
>>>Anything existing (working) or planned? My expert level: just
>>>managed to  compile a dll-hello-world version with mingw following
>>>some examples on the web :-) .
>>
>>My understanding is that there is now some level of support for DLLs
>>in libtool.
>>   http://www.belgeler.org/autobook/autobook-DLLs-with-Libtool.html
>>
>>For the Windows DLL architecture, functions that are exported or
>>imported from DLLs have to be specially declared using:
>>   __declspec(dllimport)
>>   __declspec(dllexport)
>>Normally, some preprocessor tricks are used so that a header file
>>defining a module can be used for both import and export. The
>>declaration is changed according to whether the compiled file is in
>>the same or different DLL. It would need a little thought to determine
>>what sort of model would work within oo2c. For Windows, we could add
>>these tags into the compiler-generated declarations, but this would
>>require the compiler to track which modules are grouped together in
>>which libraries. I think it already does this, but I can't say for
>>sure.
> 
> 
> The information to which shared library a module belongs to is
> available in some places, although it is not passed on into the
> generated C code until now.  The current code base writes information
> on library membership into the modules' symbol file.  Adding it to the
> header files as well should be easy, since the .oh and .Sym carry
> pretty much the same information, only in different formats.
> 
> Don't know if this is sufficient, though, since it only covers the
> identity of the used code.  It looks to me like the identity of the
> using code plays into this dllimport/export issue as well.
> 
> -- mva
> 

I don't fully understand this, but my reasoning is the following:

- A DLL is a piece of executable code.
- Once code is compiled, the source language doesn't matter any more.
- So if DLLs can be generated from C source, this should be possible
   for Oberon too.

So why would you need to know which shared library a module belongs to?
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil