Hi Przemek, >> 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.
Yes. > 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'd appreciate if you could find some to make some patches, I'll try to follow it with hbmk2. >> 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. It also causes that watcom builds cannot utilized harbour.dll created with non-watcom compiler, which is a problem, because in windows unified build I include harbour.dll built with mingw, so in effect watcom -shared mode doesn't work by default. Shipping special watcom .dlls is not a good option due to size, so maybe win/watcom libs can just be dropped from the distro as a solution, albeit a drastic one and rather a workaround. Do you see any notion or chance to fix the issue by using __cdelc for watcom? Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
