Hi, pushed the code changes to bzr ( lp:~jobinau/libdrizzle/mingwport ) Requesting your reivew.
2 points need to consider. windows 32 bit compiation defines _WIN32 windows 64 bit compilation defines both _WIN32 *and* _WIN64 so to detect whether it is windows platform we need to check _WIN32 only. final liking needs -lwsock32 -lws2_32 parameters to be passed to link against windows libraries. detailed handweaving steps i used in windows are documented here: http://drizzlenotes.blogspot.com/ Thank you, Jobin. On Sun, Jul 25, 2010 at 12:37 AM, Monty Taylor <[email protected]> wrote: > On 07/24/2010 11:11 AM, Jobin Augustine wrote: > > Happy News is that now libdrizzle fully compiles natively on MS windows. > > we got it right!. > > > > during testing, found few run time issues, but that too ironed out > > (mainly because the windows error codes retured are different than posix > > ones) > > so silly things made me crazy and took lots of time. > > EXCELLENT. > > > Monty, > > Can you guide me to push the code back to libdrizzle. > > Main part of the work is from your branch only. :) > > Yup. Continuing to chat with you on IRC about this - we'll get this all > fixed up. > > Thanks for all your work! > > > > > > > On Sat, Jul 24, 2010 at 8:54 AM, Jobin Augustine <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > >Step 1: Kill Windows > > >Step 2: live happy life. > > > > Stewart, You said it correctly. :) > > Now realizing how bad it is. > > first i tried to set up Msys (bash for windows) and other mingw > > build stuffs. > > but someway windows 7 don't like all these things. windows keeps > > crashing the configure script. :( > > > > IMHO, this confirms Monty's approch is the best for native > > compilation and in the right direction (Cross compile it from linux) > > So that we at least have properly working build environment > > > > Monty, > > lp:~mordred/libdrizzle/mingwport > > gave me a good starting. > > > > > > Robert, > > the suggested "libwinport.lib" approch is very similar to Monty's > > approch. > > gnulib's poll.c and poll.h can make a object file which an be used > > to link at the end just like your libwinport.lib. > > Thank you. > > > > Left with no weapons (configure, make etc) in windows, started hand > > weaving the compilation like: > > "C:\MinGW\bin\gcc.exe" -I. -I"C:\MinGW\include" -c > > libdrizzle\drizzle.c -o libdrizzle\libdrizzle_la-drizzle.o > > "C:\MinGW\bin\gcc.exe" -I. -I"C:\MinGW\include" -c > > libdrizzle\conn.c -o libdrizzle\libdrizzle_la-conn.o > > "C:\MinGW\bin\gcc.exe" -I. -I"C:\MinGW\include" -c > > libdrizzle\conn_uds.c -o libdrizzle\libdrizzle_la-conn_uds.o > > > > > > Thank you, > > Jobin. > > > > > > > > On Tue, Jul 20, 2010 at 3:13 AM, Stewart Smith > > <[email protected] <mailto:[email protected]>> wrote: > > > > On Sat, 17 Jul 2010 09:59:21 -0500, Monty Taylor > > <[email protected] <mailto:[email protected]>> wrote: > > > > If you rewrite something like the my_socket abstraction that > > I did for > > > > NDB win32 port, socket code should be pretty easy. > > > > > > I would strongly prefer it if we would not have any wrappers > > such as > > > this. (although I understand that in the case of NDB and MySQL > > it was > > > required) > > > > so the pain point was that you can kinda do this... except for > > closing > > sockets. close() will cause a *runtime* error popping up to the > end > > user. > > > > it is ass. > > > > maybe there's some way to get something that isn't completely > > stupid.. but at least historically (NDB porting time), there > wasn't. > > > > > Essentially, any time we have the urge to write a my_ anything, > we > > > should not. > > > > Step 1: Kill Windows > > Step 2: live happy life. > > > > -- > > Stewart Smith > > > > > > > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
