On Wed, Dec 1, 2010 at 6:23 PM, Monty Taylor <[email protected]> wrote: > On 11/30/2010 01:40 AM, Eran Ifrah wrote: >> Hello all, >> >> I came across libdrizzle and I wanted to use it as the client library >> for connecting to MySQL server. >> >> I found this branch lp:~mordred/libdrizzle/vs-build >> >> Which fails to compiles under Windows 7 / VC9 - but it seems like a >> good starting point. >> >> I made some changes to the code and it now seems to compile and run >> fine (also tested it for MinGW gcc TDM 4.4.1) >> >> My questions are: >> >> 1) Are you interested in the Windows changes I made? (which I will >> explain in details + provide patch if you are willing to accept them) > > yes please > >> 2) Is the 'vs-build' branch maintained? (according to launchpad, this >> branch was last modified 17 weeks ago...) >> 3) Are there any plans of merging the branch with trunk? > > No. It was already merged with trunk. You should see a VS solution and > project in trunk which _should_ work. However, since libdrizzle got > merged with drizzle I don't believe I've tested that the solution files > still work. >
One of the main issues I have noticed is that you provided poll() implementation for the Windows OS, however, since Windows Vista / 7 Microsoft added a new API to their socket library: WSAPoll() - which contains the MS variation to the poll() API. When building libdrizzle under Windows 7/Vista the macro _WINNT_WINVER is set to 0x0601 - this API call conflicts with the macros / structs defined in poll.h (e.g. pollfd is defined in winsock2.h and poll.h etc) to quickly fix that I could add these lines (e.g. to common.h) : #if _WINNT_WINVER >= 0x0600 #define WSAPoll poll #endif This fixes the problem under Vista / 7 but a new problem arises under XP/2003 (and is working as expected ofc) The provided "native" poll simply does not work (the one that is coded in the _WINDOWS_NATIVE macro block) Let me explain a bit: In the file poll.c there are 2 flavors of poll(): the so called "native" and the one I choose to name it "generic", if I change the macros to make it pick the generic one, every thing is working as expected ( I tested it under Windows 7/XP compiled with VC9, Windows SDK 6. And using MinGW TDM 4.4.1 (gcc 4.4.1)) - but using the "native" one - which is the default when compiling with MS Visual Studio - all my attempts to call to drizzle_query(..) returned the error DRIZZLE_RETURN_TIMEOUT (or something similar). For me, the solution was to disable the native implementation provided in poll.c and force the compiler to pick the 'generic' one (based on select()) Those were the main changes. FYI: I must say that debugging the client code was an easy task and very much readable - so good job on that one! (usually its not an easy task to debug a new code ;) ) >> >> Thanks, > > Thank you! All help is of course appreciated! > I will prepare diff files as soon as I will check out drizzle sources from bazzar. (I never used bzr before, I am an SVN user) -- Eran Ifrah Cross platform, open source C++ IDE: http://www.codelite.org _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
