Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[Nilo <nil...@gm...>]

>> David, I suppose the main environment for all the development of the
>> compiler is Linux.
>> Otherwise I would like to direct my work on the use of
>> MinGW under Windows.

>Great, I'm been waiting for a TC developer with Win32 experience for
>looong time.

I hope I can help... ;-)

>Generally speaking, compiler functionality is developed on UN*X mainly
>because it easier. Later equivalent functionality (if possible) is
>developed on Win32 using MinGW.

>The development setup I use, to keep the MinGW/UN*X TC versions in sync,
>is to have two machines on a (closed) network.
>Then using samba and Win32 shares with write access, I use the same file
>system directories.

Unfortunately I've no access to a Linux box now...

>> So I've look the portions of code related to it and have made some tests.
>>
>> During these tests I've discover that I can't call a DLL written in
TinyCobol
>> from another TinyCobol program.
>>
>> Please, could you shed me some light about the way TinyCobol generates
code
>> for Cobol written DLL's using switch '-m'? It seems to me that the
generated
>> DLL doesn't export any symbols.
>> Am I right? How should I use he compiler in order to do that?

>Have a look at the samples in the test.code/t25 and t33 directories, and
>the source code in 'htglobals.c'.
>
>Basically the export/import defines, and '.def' files are auto-generated
>by the MinGW compiler.

Well, that's the problem... a Cobol program doesn't have generated the GAS
directives that permits the exporting of symbols...

So, the MinGW compiler does not know what symbols to export...

>
>On Win32 calling a sub-program (function) in a DLL is problematic.
>
>The reason being that a DLL can contain many sub-programs (functions),
>and the name of the DLL may not have any relation to the name of the
>sub-program being called.
>
>On UN*X, there are functions calls you can use that will search the
>shared library paths and load that sub-program (function).
>On Win32 (MinGW) there is no equivalent functionality (that I am aware
>of), so you have to write your own.

Well, I made some tests and modifications on my local copy... when I call
DLL's written in C or something like that it works like a charm, without
'CALL-LOADLIB' extension. All my problems begins when I try to call DLL's
generated by TinyCobol... I'm able to find the DLL, but not the sub-programs
( functions ), just because there are no functions exported...

Maybe should the compiler export all PROGRAM-ID's identifiers as functions
names, i. e, put the '.section .drectve' and '.ascii "
-export:prog-id-name"' clauses on generated code?

Well, at least this is my first tough about... ;-)

>
>On TC version 0.63, I could not find a way to create that equivalent
>functionality. So you have to first load a specific DLL using the
>'CALL-LOADLIB identifier' extension.
>
>On TC CVS, I found a way which seams to work.
>Basically it finds, loads and checks DLL's in the 'TCOB_LD_LIBRARY_PATH'
>paths for that sub-program (function).
>See 'lib/dyncall.c' for details.

I saw your code. I would like to test it more, but the problem related to
exported symbols I told you persists....

>
>Hope this helps.
>If you have any further questions do not hesitate to ask.

Thanks, my friend. I'll try not to abuse... :-D

>
>David Essex

Nilo R C Paim
Porto Alegre - RS - Brazil