Hi Przemek,
> > ./libxhgtk.a/TWindow.o:TWindow.c:(.text+0x37): undefined reference to
> > `hb_vmExecute'
> > Do you have any idea what could be missing?
>
> Windows does not support late binding in share libraries so
> you have to add harbour.dll to linked libraru list:
> hb-mkslib libxhgtk libxhgtk.a `pkg-config --libs gtk+-2.0 libglade-2.0` \
> -lharbour
> (if necessary use also -L<path> to specify where harbour.dll is located)
> and then create Harbour shared binaries.
Nice, now there is libxhgtk.so created without errors.
> The second method is creating wrapper for Harbour API functions used
> by XHGTK and link it with xhgtk.dll.
> harbour/source/vm/maindllp.c is example of such wrapper which can be
> used with PCODE DLLs.
> Now you can simply try to add maindllp.o to above hb-mkslib command:
> hb-mkslib libxhgtk maindllp.o libxhgtk.a \
> `pkg-config --libs gtk+-2.0 libglade-2.0` \
> To see how it reduce the list of unresolved references and which functions
> are still missing and should be added.
Hm, thanks for the details here I was always wondering
what is the purpose of that file. But still, what I don't see,
is whether all these complications worth the effort? What
are the benefits?
> #define HB_DLL_NAME "harbour.dll"
> #if defined( __BORLANDC__ )
> # define HB_DLL_NAME2 "harbour-b32.dll"
> #elif defined( _MSC_VER )
> # define HB_DLL_NAME2 "harbour-vc.dll"
> #endif
I'll correct this ASAP.
Now BCC and MSVC builds uses different names for DLLs then the old
> ones defined in HB_DLL_NAME2 so this code will not detect it. I do
> not know if in Windows it's possible to extract module handle using
> wildcards, f.e. "harbour*.dll". It not then we have to define strict
> naming rules and update build script and above code keeping the names
> synced.
Did a try, but GetModuleHandle() didn't pick up
Harbour .dll at all for some reason. Maybe I just haven't
waken up properly yet.
---
PROC MAIN()
? Empty( HND("gdi32.dll") ) // .T.
? Empty( HND("harbour*.dll") ) // .F.
? Empty( HND("harbour-*.dll") ) // .F.
? Empty( HND("harbour-11-vc.dll") ) // .F.
#pragma begindump
#include <windows.h>
#include "hbapi.h"
HB_FUNC( HND )
{
hb_retptr( GetModuleHandle( hb_parc( 1 ) ) );
}
#pragma enddump
---
> /* a little bit off-topic subject */
>
> There is also small problem with functions using variable number of
> parameters like: hb_parc( int iParam, ... ) which is also related to
> other problem much more serious.
> Personally I do not like this ... extended API feature because it breaks
> code we all often used expecting default values for wrong types, f.e.:
>
> iVal = hb_parni( 1 ); /* default to 0 */
>
> If used pass array as 1-st parameter then hb_parni() tries to used
> unexisting 2-nd parameter as index to this array. On x86 machines it's
> usually access to uninitialized memory used as array index so integer
> value is extracted from the random item in passed array or 0 when it's
> out of bound. When different ABI (calling convention) is used then it
> may caused other unpredictable results. F.e. if hardware supports
> stack frame protection then it may even cause SIGSEG or sth like that.
>
> I would like to remove ... from all existing extended API functions
> and add second set which can be used for Clipper compatibility to
> replace _par*() and _stor*() functions, f.e.:
> int hb_parni( int iParam );
> long hb_parnl( int iParam );
> [...]
> int hb_vparni( int iParam, ... );
> long hb_vparnl( int iParam, ... );
> [...]
> int hb_storni( int iValue, int iParam );
> int hb_stornl( long lValue, int iParam );
> [...]
> int hb_vstorni( int iValue, int iParam, ... );
> int hb_vstornl( long lValue, int iParam, ... );
>
> Such modification resolves the problem, still allows to use hb_v*()
> functions in few places where it's usable and additional parameter
> with array index is passed.
>
> This is not directly related to .DLL problem but it's occasion to
> refresh it and maybe implement soon.
Please do it. It's a very important problem, probably
also a security hole.
Only one thing I'd suggest here, maybe hb_storniv(),
hb_*v() function names would be better here to let them
align and group well, and make grepping more straightforward.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
