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

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

On 1/3/07, David Essex <de...@us...> wrote:
>
> Nilo Paim wrote:
>
> > ...
> > Unfortunately I've no access to a Linux box now...
>
> You are aware that to use SF CVS you will require some package which has
> SSH available, such as Putty.


Oh, yes. No problems here...

> ...
> >> 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...
> > ...
> > 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... ;-)
>
> First we need to isolate the problem.
>
> What version of GCC (MinGW) are you using ?


 gcc 3.2.3

Have you tried to compile (using the Makefile.mingw) and run the
> examples found in t25 and t33 ?
> If these examples do not work, then we have a problem because they do
> work on GCC 3.x (MinGW).


Not yet. I'll do it tonight at home.

Regarding the export/import defines, the TC compiler does not generate
> any Win32 directives.
> The TC front end will spawn a process and let GCC worry about the details.


Well, that's exactly the point where I'm going to...

So if you try using 'htcobol -v -m ...' command, TC should spawn a
> process with the equivalent command.
> gcc -shared \
> -Wl,--out-implib,${lib_name2}.dll.a,--output-def,${lib_name2}.def \
> -o ${SHARED_LIB} $(OBJS) ${LIBS}


Yes, I've noted that...

So the basic method for compile time linking is as follows.
> 1) Create the DLL(s) using the sub-programs.
> 2) Create the an object from the main-program.
> 3) Add the main object and library (DLL) to the link step
>     using the '-ldll-name' GCC option.
> 4) Add the CWD to the path, and run the executable.


Well, that way the DLL is not dynamic as it could be... What's the advantage
of using DLL's if I need link it together (except for the resulting size of
the animal, of course)?

Normally I recommend using make files for DLL's because of these
> complexities.
> And because when using the TC command line you can't create DLL's
> (modules) with multiple COBOL sources (htcobol -m s1.cob s2.cob).


That's the point. I suggest that TC should do it, using as export'ed
functions all the PROGRAM-ID's names from the Cobol sources. The result I
expect is the same as I would if I code the equivalent using
'__declspec(dllexport)' in C, if you understand me...

And I think we could emit Win32 directives to the assembly code...

Anyway, have a look and let me know what you think.
>
> David Essex


Thanks a lot for your responses.

Nilo R C Paim
Porto Alegre - RS - Brazil