[FFmpeg-devel] [PATCH] IPv6 support for mingw32

Zuxy Meng zuxy.meng
Thu Jan 7 11:51:11 CET 2010


2010/1/7 Martin Storsj? <martin at martin.st>:
> On Thu, 7 Jan 2010, Zuxy Meng wrote:
>
>> 2010/1/6 Martin Storsj? <martin at martin.st>:
>> > Hi Zuxy,
>> >
>> > On Wed, 6 Jan 2010, Zuxy Meng wrote:
>> >
>> >> Without this patch mplayer build would fail but ffmpeg is fine,
>> >> because currently ffmpeg's configure disables IPv6 on Windows.
>> >
>> > Could you elaborate on how mplayer's build fails if ffmpeg is configured
>> > with IPv6 disabled?
>>
>> The problem is that the link stage would fail when CONFIG_IPV6 is set
>> for libavformat/udp.c, due to calling convention differences for
>> getaddrinfo() and freeaddrinfo().
>>
>> Without explicit options, mplayer's configure enables CONFIG_IPV6 for
>> mingw but ffmpeg's configure disables it, because the latter tries to
>> actually build a small program calling getaddrinfo(), which would fail
>> during linking.
>
> Ok, so the actual culprit in that build problem is that mplayer's
> configure forcibly enables things that ffmpeg's configure wouldn't enable,
> right?
>
>> >> There's a tradeoff however, that the built binaries can't run on Windows
>> >> 2000 or older, as getaddrinfo() and freeaddrinfo() are available as part
>> >> of the OS since Windows XP. It's possible to run IPv6 on Windows
>> >> 2000/ME/98 with IPv6 Technology Preview installed but that requires
>> >> inclusion of wspiapi.h that isn't shipped in MinGW due to license
>> >> conflicts.
>> >
>> > Skipping backwards compatibility for this kind of feature isn't something
>> > I'd do lighthandedly.
>> >
>> > The common approach to preserve backwards compatibility (without losing
>> > the IPv6 functionality on the newer versions that actually have a proper
>> > getaddrinfo) on windows is to load them using GetProcAddress, and provide
>> > a fallback wrapper if they aren't found. Fallback wrappers already are
>> > provided in the "[PATCH/RFC] Prefer getaddrinfo over gethostbyname"
>> > thread, so adding support for loading the proper ones on top of those
>> > patches is quite easy. I can give that a try.
>>
>> Actually there is a wspiapi.h that just does that. However it's
>> copyrighted by MS. You can take a look at it from
>> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html for
>> reference.
>
> There's no need for that, I've already made a reimplementation of my own -
> see the latest patches in the other thread.
>
> In the latest patch series in that thread, I first remove the checks for
> getaddrinfo in the CONFIG_IPV6 check, since we already provide fallbacks
> for that function. I also add the winsock headers to the CONFIG_IPV6
> check, so that the check succeeds on mingw.
>
> If I understand the mplayer build problem correctly, this is enough to
> make things work in that build configuration, right?
>
> The last patches in that series enable actual IPv6 support on windows,
> either by loading getaddrinfo & co dynamically (roughly equivalent to what
> wspiapi.h does) or by linking directly to the symbols (and thus requiring
> XP).

Great! Maybe we can provide an option to choose one from the two
solutions. Anyway thanks for your enormous effort in resolving the
whole thing.

>
> But as for the mplayer build problem, neither of these actually are
> required for fixing the build problem - if patches up to 0011 in the
> series are applied, the build problem should be fixed.
>


-- 
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6



More information about the ffmpeg-devel mailing list