>> 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>> ; TODO: Couldn't find how to pass .def files to Open Watcom wlink.
>> Anybody with an experience here?
Just reinforced the question in another mail before
reading this e-mail of yours.
> As I can see OW supports .def files only in 'link' command and
> wlink uses a little bit different format. It's necessary to use
> EXPORT command in .lnk file or include separate file with such
> definitions using @<filename> command.
> Here are commands I used with Open Watcom:
>
> EXPORT DllGetClassObject = '_dllgetclassobj...@12' PRIVATE
> EXPORT DllCanUnloadNow = '_dllcanunload...@0' PRIVATE
> EXPORT DllRegisterServer = '_dllregisterser...@0'
> EXPORT DllUnregisterServer = '_dllunregisterser...@0'
> EXPORT DllMain = '_dllm...@12'
>
> We can add function which will translate .def files to this format
> or we can leave it for users and include them as separate in link
> script. But here we still have the problem that HBMK2 ignores
> commands like
> -ldfl...@myolesrv.def
> Viktor for me it's a bug which should be fixed. Why you decided
> that HBMK2 should ignore compiler and linker command specified by
> user if they do not start with "-" character?
> In my opinion any <text> passed as -*flag=<text> should be passed
> to corresponding Harbour/C compiler/linker and HBMK2 should not
> silently ignore only some of them. In some situations like above
> it's serious limitation.
Above should be solved differently. hbmk2 should handle
such input files transparently. I don't see it huge problem,
given that you're now trying to push the tool into its
limits before having these features added natively to hbmk2.
Not a typical use-case.
So the key is '@'. Plus a different format. I vote to
create an automatic converter to not put the burden on
users to make the conversion manually, and make it
easy to switch between compilers.
Anyhow I will add support for .def files (as-is) for now
by passing them with '@' prefix. Later we can think about
automatic conversion. It will require some ugly watcom
specific hacks unfortunately. (why oh why did watcom opt
for a non-standard solution. again.)
BTW, Sybase was bought by SAP. Along with Open Watcom
and ADS.
> There is also yet another important problem with current OpenWatcom
> MS-Windows builds. Current harbour OW build time switches forces
> stack calling convention and not all Open Watcom libraries are compiled
> in this mode. It causes that it's not possible to use some extensions
> like OLE code due to unresolved external, i.e. try to link
> contrib/hbwin/tests/testax.prg
> If user wants to use OLE with Open Watcom builds then it has to
> recompile whole Harbour code with:
> HB_USER_CFLAGS=-6r
> and then use -cflag=-6r HBMK2 parameter.
> Can we switch back OpenWatcom builds to its default calling convention?
Sure we can.
This means switching from -6s/-3s modes to -6r/-3r,
is that right?
I can't remember why we switched to non-default though
this the closest I could quickly find, seems resolved
though:
2009-03-31 02:58 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
...
* config/win/owatcom.cf
% Pentium Pro scheduling.
* Changed back to __cdecl calling convention from register based
until we find a way to tweak HB_EXPORT to force __cdecl for
.dll exported functions.
; TOFIX: Find out how to force __cdecl for HB_EXPORT functions in owatcom.
Or, if this is no good solution for owatcom users, or not
an option and performace is more important, we must rename
owatcom Harbour .dlls to a distinct name: harbour[mt]-11-ow.dll.
We should try to avoid that. [SOLVED]
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
