On Wed, 26 May 2010, Szak�ts Viktor wrote: Hi Viktor,
> Another thing I noticed is that I cannot build > watcom servers, not clients. For servers it > complains about 'Error! E2030: file clib3s.lib(cstrtwwt): multiple starting > addresses found', > for clients there are unresolved symbol, even > if I comment the special -cflag in .hbp. You have to recompile whole Harbour core code with HB_USER_CFLAGS=-6r to resolve insufficient dependencies. The multiple entry points are probably caused by DllMain() in hbwin.lib and WinMain() in hbvm.lib so linker does not know which one should chose. Maybe it can be resolved by adding some linker command to hbolesrv-watcom.def. For sure it can be done by linking hbolesrv.c directly not from library. In such case linker gives higher priority to code in .obj files so takes DllMain() from hbolesrv.obj before begins to scan libraries. If you link OLE server dynamically then it also resolves this problem. Alternatively we can move WinMain() to separate library or remove strict binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which will force linking with WinMain() if necessary (GUI application is created). hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom versions and maybe can be eliminated now or maybe it's enough to add some commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference from watcom builds should resolve the problem. You only have to check if HBMK2 can still create static GUI binaries for using OW. > I think watcom should truly be fixed by switching > to default callconv on the Harbour level, though > in this case for win/watcom builds all HB_EXPORT > declarations need have a __cdecl modifier added > between return type and function name. And this is > currently not possible without creating a new scheme > for public C function declaration (at least I could > not find a painless solution). The problem is only for users who will want to use harbour.dll created by Open Watcom with some other C languages so it's not very common. Probably we should ignore it now switch to register calling convention and then if possible look for some solutions which can force using C calling convention for exported Harbour functions. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
