On Wed, 18 Mar 2009, Szak�ts Viktor wrote:
Hi,
> 1) One problem with this is that an .exp / .lib file will be generated
> for *every* Harbour executables created, at least with MSVC. This
> is because these two symbols will now be exported from all
> Harbour executables. [ I've been dealing with this issue in the last
> few months quite heavily. ]
> 2) It won't solve -gc3 compiled .prg code. These need some more
> functions to be exported.
> 3) I'd use some other name, like HB_EXPORTFORCED, because
> the meaning of 'p' is very ambiguous (it was "*p*code dynamic lib
> probably, but this isn't precise).
If you export at least one symbol then you automatically disable
automatic conversion in MinGW builds. This conversion is enabled
only if application does not export any other symbols. It means
that in MinGW builds you will have to introduce to compilation
phases just like in other builds.
> 4) It's still unclear what is the importance of maindllp.c, as it's not
> used anywhere inside Harbour.
It has to be linked with DLL library created bu user. It allows to
use such DLL with static (of course if symbol used in maindllp.c are
exported) and dynamic (using harbour.dll) Harbour applications.
> I'd rather say to use HB_DYNLIB option by those who'd like this
> functionality. I'd expect it's not widely used by too many ppl, as
> such bugs have been unnoticed for at least 8 years :) Maybe there
> are other solutions without downsides.
IMHO it is widely used. Just check in the archive how many people asked
about it when __EXPORT__ macro name was changed to HB_DYNLIB. I guess
that so far most of users updated their build scripts and JF is one
of the last one. In xharbour.news you can also find that people quite
often ask how to make own .DLLs or how to use own .DLLs without
xharbour.dll but with static binaries (AFAIR some of them asked about
it on this list too).
> [ A possible one is to have stubs for these exported functions,
> and these stubs be placed in a separate lib which would always
> be built with exported symbols. This would need special Harbour
> switch to generate code for these stubs. Probably -gc3 mode
> should be disabled in such mode. ]
Yes, it's interesting solution. maindllp.c should be updated to look
also for alternative names of above functions. This new library should
not be a part of harbour.dll.
In such case it will be enough if user will add to his code linked
in static part of application a REQUEST, f.e.:
REQUEST HB_EXPORT
to force linking the library module. Or we can simply use .obj file.
In such case it will be enough to link it. We can also add an option
to hbmk2 to link such .obj file.
Such separated code linked with static part of applications resolves
also other problem. It's not necessary to know the exact name of
harbour.dll in dynamically linked applications. In fact we need only
one symbol to be exported. It can be function which will return addresses
of any other functions necessary for loaded module, f.e.:
HB_EXPORT FARPROC hb_getProcAddres( int iFunc )
{
switch iFunc:
case 1;
return ( FARPROC ) &hb_vmExecute;
case 2;
return ( FARPROC ) &hb_vmProcessDllSymbols;
[...]
default:
return NULL;
}
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
