Hi,
>>>> Isn't it a solution if we move HB_LIBLOAD() to a separate
>>>> .c file along with above trigger code, and in this way,
>>>> if an executable uses this functionality, above stub is
>>>> always included?
>>> No because it will disable autoexport functionality in MinGW
>>> builds.
>> Hm, even if it's not linked, just present in the static lib?
>
> Are you planing to remove HB_LIBLOAD()/HB_LIBFREE() from harbour*.dll?
> If yes then it can be done in such case.
We can do it. Though in this case it won't be possible to
load pcode .dlls to -shared lib, right? (well, or some other
meaningful combinations, you oversee this much better.)
>> That could have been hugely elegant, I find the switch not
>> very much so :(
>
> OK, I'll document:
>
> #pragma begindump
> #include "hbapi.h"
> HB_EXPORT_ATTR PHB_FUNC dll_hb_vmProcAddress( const char * szFuncName )
> {
> return hb_vmProcAddress( szFuncName );
> }
> #pragma enddump
I've came up with -hbexedyn switch name idea (which is same as -hbexe,
but generates this extra code in stub), though if possible it'd still
be better to make it automatic.
Another idea, and this looks the best so far. Why not introduce
a symbol which can be REQUESTed from app code, if someone wants
to enable pcode loading feature?
F.e.
REQUEST HB_LIB (or HB_LIBDYN...)
This would pull above code from a separate .c file, which .c file
wouldn't be part of harbour*.dll, only reside in static lib with
no reference to it from Harbour code code.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
