[Winpcap-users] [PATCH] mingw build

Alon Bar-Lev alon.barlev at gmail.com
Tue Oct 19 10:33:29 PDT 2010 

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
>

More information about the Winpcap-users mailing list