Hi, There seem to be a large number of warnings generated during the Windows/Cygwin build relating to the type of arguments provided to various support functions.
The functions seem to be mostly prototyped in platform includes such as /usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h The warnings are of this flavour /usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h:1796:24: note: expected 'PDWORD' but argument is of type 'guint32 *' I have been experimenting with declaring some of the prototypes within the build environment instead of in those platform incldues but there's so much of this I am at a bit of a loss as to how to proceed. I am now wondering if it is better to pull in winbase.h / winsock2.h and rewrite them to take the gint* style. I'm not terribly keen on that idea. That or maybe there's a way to make gint32 and friends appear as LONG and the equivalents and so forth, although that also seems less than ideal. Can anybody advise on a sensible way for me to approach this? Thanks, Alex -- Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/> Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374 Linkedin <http://www.linkedin.com/in/alexjlennon> Skype <skype:alexjlennon?add> This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
