[Winpcap-users] [PATCH] mingw build

Gianluca Varenni gianluca.varenni at cacetech.com
Tue Oct 19 17:39:11 PDT 2010 

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" <alon.barlev at gmail.com>
Sent: Tuesday, October 19, 2010 10:33 AM
To: <winpcap-users at winpcap.org>
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
> <gianluca.varenni at cacetech.com> wrote:
>>
>>
>> --------------------------------------------------
>> From: "Alon Bar-Lev" <alon.barlev at gmail.com>
>> Sent: Tuesday, October 19, 2010 12:16 AM
>> To: <winpcap-users at winpcap.org>
>> 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
>>> <gianluca.varenni at cacetech.com> 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" <gianluca.varenni at cacetech.com>
>>>> Sent: Tuesday, October 12, 2010 9:43 AM
>>>> To: <winpcap-users at winpcap.org>
>>>> Subject: Re: [Winpcap-users] [PATCH] mingw build
>>>>
>>>> >
>>>> >
>>>> > --------------------------------------------------
>>>> > From: "Guy Harris" <guy at alum.mit.edu>
>>>> > Sent: Wednesday, October 06, 2010 5:02 PM
>>>> > To: <winpcap-users at winpcap.org>
>>>> > 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
>>>> >> Winpcap-users at winpcap.org
>>>> >> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>>> >
>>>> > _______________________________________________
>>>> > Winpcap-users mailing list
>>>> > Winpcap-users at winpcap.org
>>>> > https://www.winpcap.org/mailman/listinfo/winpcap-users
>>>>
>>>> _______________________________________________
>>>> Winpcap-users mailing list
>>>> Winpcap-users at winpcap.org
>>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>> _______________________________________________
>>> Winpcap-users mailing list
>>> Winpcap-users at winpcap.org
>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>>
>> _______________________________________________
>> Winpcap-users mailing list
>> Winpcap-users at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>

More information about the Winpcap-users mailing list