Alon, sorry for taking so much time in getting back to you. I've been extremely busy after the recent acquisition and I haven't found time to work on it. I plan to work again on it within the next couple of weeks.
Have a nice day GV From: Alon Bar-Lev Sent: Thursday, October 21, 2010 4:10 AM To: [email protected] Subject: Re: [Winpcap-users] [PATCH] mingw build 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
_______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
