[FFmpeg-devel] [PATCH] Enable proper IPv6 functions on windows

Reimar Döffinger Reimar.Doeffinger
Sat Jan 16 00:31:39 CET 2010

On Sat, Jan 16, 2010 at 12:49:44AM +0200, Martin Storsj? wrote:
> On Fri, 15 Jan 2010, Reimar D?ffinger wrote:
> > May I say: WTF are you doing?
> > The defines do not matter one bit, just set -D_WIN32_WINNT=0x0501 and be done
> > with it, that is not an issue _whatsoever_.
> Well, IMO setting the define is a good way to be able to use the normal 
> configure checks to see what's available at the platform version we're 
> targeting. So instead of littering the actual code with platform specific 
> hacks, we simply check if function foo is available on the target 
> platform.

Except that Windows is not Linux in that you can't expect a binary to (more
or less) run where it was compiled. It's about as beautiful as a the square
pressed through the round hole.

> > Disabling gettaddrinfo sure is possible, but
> > a) no need to hack the defines for that
> > b) what is the big deal with just not enabling getaddrinfo with HAVE_WINSOCK2_H
> > and start ff_get_procaddres with
> >   int WSAAPI (*wingetaddrinfo)(const char *, const char *, const struct addrinfo *, struct addrinfo **);
> >   HMODULE ws2mod = GetModuleHandle("ws2_32.dll");
> >   wingetaddrinfo = GetProcAddress(ws2mod, "getaddrinfo");
> >   if (wingetaddrinfo)
> >     return wingetaddrinfo(...);
> > #endif
> I proposed a version of that, too, in 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/080687.html
> but the simpler way to simply link directly to the getaddrinfo function 
> was preferred by Ronald, in this follow-up:
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/080708.html

Your approach uses an actual Load/Unload step in a special function,
which IMO pointlessly complicates things.
Even if LoadLibrary was needed you can just do Load, call function unload.
Also I can not see the thread safety issue with dynamic loading, we are talking
about a library we are _linking_ to, you're not going to tell me Windows will
unload a Library you _linked_ to?

> But yes, that would be the most compatible solution, ending up with a 
> binary compatible with older platforms and still being able to utilize the 
> newer functions when available.

Actually I'd be happy to just avoid the impenetrable and in half the cases
simply working wrong (wince is only one case, and how will your wince hacks
work if wince ever gets IPv6 support?) configure mess this is accumulating.

More information about the ffmpeg-devel mailing list