I use the simple way... Gentoo's crossdev
crossdev -t i686-w64-mingw32 crossdev -t x86_64-w64-mingw32 On Wed, Oct 20, 2010 at 2:39 AM, Gianluca Varenni < [email protected]> wrote: > That should work. > > Can you tell me the exact steps and environment that you use to target > 32bit > with MINGW64? > > Have a nice day > GV > > > > -------------------------------------------------- > From: "Alon Bar-Lev" <[email protected]> > Sent: Tuesday, October 19, 2010 10:33 AM > To: <[email protected]> > Subject: Re: [Winpcap-users] [PATCH] mingw build > > > Hi, > > > > No I don't use -m32, you can build cross compile that targets 32bit > > without multilib... > > But it is not such important. > > > > What I am suggesting is a simple Makefile rule, or just use the > > autoconf provided with libpcap anyway... but if not, please consider > > the following, then #include config.h, and use its constants to > > conditionally do whatever. > > > > target: config.h > > > > config.h: > > -rm config.h config.h.tmp > > touch config.h.tmp > > echo "#include <windows.h>" > conftest.c > > echo "#include <ntddndis.h>" >> conftest.c > > $(CC) -c conftest.c > /dev/null 2>&1 && echo "#define > > HAVE_NTDDNDIS_H 1" >> config.h.tmp || true > > echo "#include <windows.h>" > conftest.c > > echo "#include <ddk/ntddndis.h>" >> conftest.c > > $(CC) -c conftest.c > /dev/null 2>&1 && echo "#define > > HAVE_DDK_NTDDNDIS_H 1" >> config.h.tmp || true > > echo "int getaddrinfo();int main(void){getaddrinfo();}" > > > conftest.c > > $(CC) conftest.c -lws2_32 > /dev/null 2>&1 && echo "#define > > HAVE_GETADDRINFO 1" >> config.h.tmp || true > > mv config.h.tmp config.h > > > > > > > > On Tue, Oct 19, 2010 at 6:51 PM, Gianluca Varenni > > <[email protected]> wrote: > >> > >> > >> -------------------------------------------------- > >> From: "Alon Bar-Lev" <[email protected]> > >> Sent: Tuesday, October 19, 2010 12:16 AM > >> To: <[email protected]> > >> Subject: Re: [Winpcap-users] [PATCH] mingw build > >> > >>> Hi, > >>> > >>> This is incorrect: > >>> --- > >>> #ifdef __MINGW32__ > >>> +#ifdef __MINGW64__ > >>> +#include <ntddndis.h> > >>> +#else /*__MINGW64__*/ > >>> #include <ddk/ntddndis.h> > >>> +#endif /*__MINGW64__*/ > >>> #else > >>> --- > >>> > >>> As mingw-w64 can be used as both 32bit and 64bit (i686-w64-mingw32, > >>> x86_64-w64-mingw32). > >>> So you fix this for 64bit but if you use 32bit you will get the same > >>> error. > >> > >> I think I know what you mean now (after searching more on the internet). > >> You > >> are using MINGW64 *and* the option -m32 to generate 32bit binaries. I > >> didn't > >> know about the existence of -m32 ... > >> > >> Regarding the addition of the ddk include in the makefile, the reason > why > >> I > >> didn't do that is because I couldn't find a definition of the default > >> include folder for that specific toolchain (and that works on mingw, > >> mingw64, mingw64 with -m32, linux, windows, cygwin). Ideally the > addition > >> should be something like > >> > >> CFLAGS = ........ -I ${default_include_dir}/ddk > >> > >> but I haven't found what is the right env variable that I should put in > >> place of "default_include_dir". I don't want to put an absolute path > >> there. > >> > >> I'm definitely open to suggestions... > >> > >> Have a nice day > >> GV > >> > >> > >>> > >>> What I recommend is to add ddk include file LAST in the CPP search > >>> list in make file. > >>> > >>> Same goes to: > >>> +/* > >>> + * Mingw64 has its own implementation of getaddrinfo, mingw32 no > >>> + */ > >>> +#ifndef __MINGW64__ > >>> + > >>> + > >>> > >>> Best to have it done in Makefile, by trying to compile something with > >>> getaddrinfo and create mini config.h file. > >>> > >>> If you want I can create such a patch. And if we do this, we can also > >>> check if the ddk is needed or not using the same method. > >>> > >>> Regards, > >>> Alon Bar-Lev. > >>> > >>> On Tue, Oct 19, 2010 at 12:19 AM, Gianluca Varenni > >>> <[email protected]> wrote: > >>>> > >>>> I reworked the patch originally provided by Alon Bar-Lev (thanks!) a > >>>> bit > >>>> to > >>>> have WinPcap 4.1.2 compile under MINGW32 and MINGW64, Windows and > Linux > >>>> cross compilation. > >>>> > >>>> You can find it at > >>>> > >>>> http://www.winpcap.org/install/bin/WinPcap_4_1_2_mingw_win.patch > >>>> http://www.winpcap.org/install/bin/WinPcap_4_1_2_mingw_linux.patch > >>>> > >>>> MD5's are as follows: > >>>> > >>>> 6cecf64649cfd4f32553025d2b6daa96 *WinPcap_4_1_2_mingw_linux.patch > >>>> 8b341ba39bb0b621c81f5c8df7e7536a *WinPcap_4_1_2_mingw_win.patch > >>>> > >>>> Due to a big mess with line endings in the source code of WinPcap > 4.1.2 > >>>> (some files have the CR/LF line ending, some have the LF one), the > >>>> patch > >>>> that was working on Windows (with patch.exe coming from cygwin or > >>>> MSYS) > >>>> was > >>>> not working on linux, and viceversa. So I created two patch files for > >>>> WinPcap 4.1.2. > >>>> > >>>> The resulting patched WinPcap 4.1.2 was tested on > >>>> - Cygwin 1.7 > >>>> - MSYS+MINGW64 (I used the TDM-GCC one at http://tdm-gcc.tdragon.net/ > ) > >>>> - MSYS+MINGW32 (I used the TDM-GCC one at http://tdm-gcc.tdragon.net/ > ) > >>>> - MINGW32 on a debian "squeeze" machine > >>>> - MINGW64 on a debian "squeeze" machine > >>>> > >>>> Also, the same patches were committed on the WinPcap repository + > >>>> libpcap > >>>> repository (HEAD and libpcap_1.1 branch). > >>>> > >>>> Have a nice day > >>>> GV > >>>> > >>>> > >>>> > >>>> -------------------------------------------------- > >>>> From: "Gianluca Varenni" <[email protected]> > >>>> Sent: Tuesday, October 12, 2010 9:43 AM > >>>> To: <[email protected]> > >>>> Subject: Re: [Winpcap-users] [PATCH] mingw build > >>>> > >>>> > > >>>> > > >>>> > -------------------------------------------------- > >>>> > From: "Guy Harris" <[email protected]> > >>>> > Sent: Wednesday, October 06, 2010 5:02 PM > >>>> > To: <[email protected]> > >>>> > Subject: Re: [Winpcap-users] [PATCH] mingw build > >>>> > > >>>> >> > >>>> >> On Sep 14, 2010, at 9:17 AM, Alon Bar-Lev wrote: > >>>> >> > >>>> >>> 4. grammar.y - any idea why we need pcap_parse if yacc defines it > >>>> >>> anyway instead of yyparse? > >>>> >> > >>>> >> Because > >>>> >> > >>>> >> 1) WinPcap is based on libpcap; > >>>> >> > >>>> >> 2) libpcap was originally written back when many UN*Xes had only > the > >>>> >> old > >>>> >> AT&T YACC, which only defined yyparse(). > >>>> >> > >>>> >> The current top-of-trunk version of grammar.y, at least, defines > >>>> >> pcap_parse() only if YYBISON is not defined, which presumably means > >>>> >> "not > >>>> >> Bison". > >>>> >> > >>>> >>> 5. yacc does not accept -y argument. > >>>> >> > >>>> >> Earlier versions of GNUmakefile mirrored the UN*X Makefile.in, and > >>>> >> had > >>>> >> a > >>>> >> YACC variable that ran Bison, rather than YACC, with the "-y" flag > >>>> >> (which, > >>>> >> for Bison, means "act like YACC and produce y.tab.c and y.tab.h > >>>> >> files"). > >>>> >> > >>>> >> The 4.1.2 version runs whatever make sets YACC to refer to, with > the > >>>> >> YFLAGS flag. Is there some reason why that was done? > >>>> > > >>>> > No idea. The original GNUMakefile was contributed by someone and > >>>> > included > >>>> > into the WinPcap sources. > >>>> > I modified GNUMakefile to > >>>> > 1. define "BISON = bison" and "FLEX = flex" > >>>> > 2. use ${BISON} to compile grammar.y > >>>> > > >>>> > > >>>> >> Was this to support parser-generators *other* than Bison? Unless > >>>> >> there's > >>>> >> a compelling reason not to run Bison, it should probably go back to > >>>> >> the > >>>> >> way it was, using Bison - that'll fix that problem *and* the > >>>> >> previous > >>>> >> problem, with no changes required to grammar.y. > >>>> >> > >>>> >> If there *is* a compelling reason not to run Bison, then > >>>> >> > >>>> >> 1) it should not include "-y" > >>>> >> > >>>> >> and > >>>> >> > >>>> >> 2) either it should not do "-p pcap_", if whatever version of YACC > >>>> >> is > >>>> >> being used doesn't support "-p", or: > >>>> >> > >>>> >> 2a) grammar.y should check for YYBISON *and* some other #define > >>>> >> named > >>>> >> appropriately for whatever parser-generator is being used > >>>> >> > >>>> >> and > >>>> >> > >>>> >> 2b) it should do "-D{that #define name}". > >>>> >> > >>>> >>> 7. Minor modification of (char*)A += code. > >>>> >> > >>>> >> (I.e., "casting lvalues considered harmful - and possibly rejected > >>>> >> by > >>>> >> some > >>>> >> compilers.") > >>>> > > >>>> > I will commit it on the libpcap git repository as soon as possible. > >>>> > > >>>> > Have a nice day > >>>> > GV > >>>> > > >>>> >> _______________________________________________ > >>>> >> Winpcap-users mailing list > >>>> >> [email protected] > >>>> >> https://www.winpcap.org/mailman/listinfo/winpcap-users > >>>> > > >>>> > _______________________________________________ > >>>> > Winpcap-users mailing list > >>>> > [email protected] > >>>> > https://www.winpcap.org/mailman/listinfo/winpcap-users > >>>> > >>>> _______________________________________________ > >>>> Winpcap-users mailing list > >>>> [email protected] > >>>> https://www.winpcap.org/mailman/listinfo/winpcap-users > >>> _______________________________________________ > >>> Winpcap-users mailing list > >>> [email protected] > >>> https://www.winpcap.org/mailman/listinfo/winpcap-users > >>> > >> _______________________________________________ > >> Winpcap-users mailing list > >> [email protected] > >> https://www.winpcap.org/mailman/listinfo/winpcap-users > >> > > _______________________________________________ > > Winpcap-users mailing list > > [email protected] > > https://www.winpcap.org/mailman/listinfo/winpcap-users > > > _______________________________________________ > Winpcap-users mailing list > [email protected] > https://www.winpcap.org/mailman/listinfo/winpcap-users >
_______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
