-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xHarbour compatibility restored #27
Comments
I´m very excited to download it again and give it another try to compile with xharbour, very happy to hear that news! |
Hooray! ...;-) make_b32 all Well, in my system I did this before FUNCTION MAIN():
And then after FUNCTION MAIN():
And forwards:
|
Hi Numerabilis, i recently have excluded function: Leto_GetLocalIP() for xharbour, to spare 2 Windows ! libs You only need the rddleto.lib for [x]harbour. Meanwhile i am on the track what goes wrong for xharbour related to LZ4. About C-compilers: these stand between your [plus xharbour] source code and your machine CPU. best regards |
May God give you wisdom! I wish you best luck! |
Hi Numerabilis, as explained in last post: two Windows libraries must be linked. Scroll down to the very bottom, there -> : Requirements : Library Tl;Dr; -- Ws2_32.lib, Iphlpapi.lib in BCC58/lib/PSDK |
Ok, thanks! But before I had to change my 3 CFG files from BCC58/BIN to include the "BCC58/lib/PSDK" path as shown below:
ILINK32.CFG TLINK.CFG Then it compiled with no errors! Hooray! |
Well, LETO_GETLOCALIP won´t exist in xHarbour but I still had to link those 2 Windows LIBs. I thought you meant I wouldn´t need them anymore. |
LETO_DIRECTORY() is not working on xharbour. |
Hi Numerabilis,
xHarbour 'downward' compatibility have got lost over the time,
No wonder, as there wasn't any feedback from them since Patrick Mast asked me years ago.
it caused me significant work to restore it ...
But now again i can produce a rddleto.lib with 'no real warnings' ... ;-)
#) As there is no 'hb_znet' for z-lib compressed network traffic in xHarbour,
they * must * use my LZ4 implementation for that.
Network encrypted traffic is bound in LetoDBf to traffic compression,
as else you can easyily live without compression for that.
Data compression is else applied at some very specific points in LetoDBf, so in the end you will want to have that.
**
Until now LZ4 is NOT working for xHarbour - it works absolutely great for Harbour,
even for BCC 5.8.2.
In xHarbour it leads to a GPF crash of the app when activated.
I still haven't found the origin cause for that - sadly there is no Valgrind for Windows.
The problem could be bound to specific C-compilers for xHarbour,
or more propably the problem is inside LetoDBf/ LZ4.
Could be even an easy silly bug, and i just don't recognize it -- need more time to find the bug, tips extremely welcome.
**
So for testing purpose, to let us go on, i created dummy LZ4 functions so that the app can build.
This is done by setting the 'LZ4_DUMMY' flag for c-source and leaving away the lz4.c so far.
I uploaded a new xBuilder rddleto.lib.xbp definition for xHB,
as also a new make_b32.bat for BCC >= 5.8.2 for xharbour -- use it without any argument to get a rddleto.lib.
PellesC makes me headaches, even newest Harbour itself can not be build from source with it out the box.
The C-compiler have some serious problems, at very least about complex 'pre-processor directives',
[ that are e.g. these '#if defined ( xxx ) && ( xxx > y ) .. and more complex ones ]
Older versions of PellesC just produce garbage from lz4.c.
--
The whole section in the Readme.txt for xHarbour needs rework -- suggestions welcome !
Also i would be kindly interested about how you are building the final app,
as no xHarbour version has this abolutely famous 'hbmk2' make tool by Szakats from Harbour.
By the way, you are using xHB or xharbour ?
best regards
elch
The text was updated successfully, but these errors were encountered: