← Back to team overview

drizzle-discuss team mailing list archive

Re: Drizzle on MS windows

 

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.

Monty,
Can you guide me to push the code back to libdrizzle.
Main part of the work is from your branch only. :)

Thank you,
Jobin.




On Sat, Jul 24, 2010 at 8:54 AM, Jobin Augustine <jobinau@xxxxxxxxx> 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 <stewart@xxxxxxxxxxxxxxxx>wrote:
>
>> On Sat, 17 Jul 2010 09:59:21 -0500, Monty Taylor <mordred@xxxxxxxxxxxx>
>> 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
>>
>
>

Follow ups

References