Hi Przemek, >> I got a large number of unresolved externals. I think > > Because you haven't recompiled whole Harbour code with > -r6 watcom compiler switch.
I know, I use default build. Most users will use default build, so that's what we shall make work. >> we should handle the watcom problem as a whole. Until >> then hbolesrv.c can just be added after regular >> server sources to solve the multiple entry problem. > > For me this are two different things. > 1. broken watcom binaries due to forces stack calling convention. It's broken either way. Default is broken for OLE servers, special build is broken for non-watcom Harbour .dlls. > 2. chosing startup entry point for created binaries and interaciton > with existing hack with hb_forceLinkMainWin()/hb_forceLinkMainStd(). I never got that topic, so all I can add is that it would be great to drop any hack, including this one, if possible :) >> Plus there is also the distribution problem. Overall >> it'd be much cleaner to have everything in hbwin lib, >> since it's required anyways. > > I agree with having everything in hbwin lib. But for this we > have to remove or update hb_forceLinkMainWin()/hb_forceLinkMainStd() > bindings from hvm.c and adopt and if necessary adopt for this > modification link command in GNU make system and HBMK2. Okay with me. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
