Hi Przemek,
So, to give a short list of Windows .dll problems:
- 'sed' command line error.
This is probably caused by the C: prefix in your paths.
Probably if you use /c/ instead then this message will
disappear. I'll try to located it and add some workarounds.
Thanks, I'll update my environment anyways, better be
friendly with msys.
I've changed C: to /c/ everywhere except the PATH.
[ but it didn't fix the sed problem. ]
- harbour*.dll naming in non-GNU make system.
- harbour.dll install location doesn't match in GNU ('lib') and non-
GNU ('bin') builds.
I know about it but I left for user decisions where to put it.
Anyhow if other non GNU Windows make systems store harbour*.dll
in HB_BIN_INSTALL then I can update postinst.sh to make the same.
That would be great. If it's in lib, one has to always fiddle
with either copying it next to the .exe, or to some system dirs,
or to put the lib dir in the path, I personally hate to do any
of these (especially the latter two).
- harbour.dll content doesn't match in GNU and non-GNU (missing
hbcplr) builds.
Yes but probably we should remove hbcplr from commercial builds.
There is still open question about rewriting some part of compiler
which uses pure GPL license with different license similar to Harbour
exception but which will have additional condition: any binaries
created
from modified version of this code (directly on indirectly by some
macros) has to be distributed with modified source code and build
scripts so each user should be able to replicate exactly the same
version of hbcplr library.
But this is other subject. I'll exclude hbcplr from harbour shared
libraries before final release.
Thanks, I think it is the way to go (excluding the compiler stuff
from harbour.dll).
- harbour.dll generated with BCC isn't compatible with MSVS and MinGW
ones (due to added leading underscore in BCC).
Yes and I do not know if it's possible to make MSVC compatible library
using BCC.
That would be a huge shame on BCC...
- Minor: Generation of harbour.dll using the GNU-make system under
Windows, needs full msys shell support. Maybe it would be better to
include
this process in the GNU-make system itself (if possible at all).
It rather needs bash only and some GNU/MinGW tools. It can be resolved
when we add alternative version of hb* tools written in .c. Now they
are BASH scripts only.
Isn't it a possibility to somehow integrate the .dll creation
process into the GNU-make system? (rather than having a separate
post-script to do it)
It's not a huge problem to use msys to create MinGW builds though
(once you got through the initial gotchas).
- MinGW generated shared-lib .exe is not compatible with MSVS
generated
harbour.dll. (missing '[EMAIL PROTECTED]' entry)
Can you check how this symbol looks in the final MSVC dll?
It probably have some very similar name. It can be different
in pure C and C++ builds.
Well, there is no "WinMain" at all in harbour-vc.dlls, but
there is one '?DllEntryPoint@@....' in C++, and a
'[EMAIL PROTECTED]' in C.
Please also try to make console application by adding to hbmk -
lmainstd
switch, f.e.:
hbmk -n -w -es2 -lmainstd -gtstd hbrun
I've changed mainstd to hbmainstd, and it worked altough the
result looked quite strange :), after that I've rebuilt it
with -shared, and it gave a 'compress2' missing entry.
Which pbly indicates that hbzlib is missing from harbour.dll
in non-GNU make.
After this I reduced hbrun.prg to a pure 4 lines long program
displaying hb_compiler() and waiting for a key. Then it told
's_defaultGT', and at this point I'm pretty much lost.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
