libdvdread uses internal dlfcn on W32, unconditionally
authorLRM <lrn1986@gmail.com>
Tue, 17 Apr 2012 17:40:41 +0000 (10:40 -0700)
committerJean-Baptiste Kempf <jb@videolan.org>
Tue, 5 Feb 2013 17:41:52 +0000 (18:41 +0100)
commitc922fa66f7c0c2e0fb7b68ba69a8c29a78b2f273
tree4e2125e3ba82b1ae99685089c3f4cad6dd67c273
parent21324a7b15411b3beb181a848aa838f8d2f0143d
libdvdread uses internal dlfcn on W32, unconditionally

On W32 libdvdread unconditionally uses msvc/contrib/dlfcn.c
While this allows libdvdread to be compiled out of the box, it
prevents it from linking to any other dlfcn implementation. Namely -
to dlfcn-win32 [1] (which is somewhat more POSIX-compliant).

The attached patch is very simplistic (i.e. it unconditionally
requires a working libdl somewhere), but it works for me. For trunk i
would suggest re-writing it like this:
check for dlopen in -lc
 if that fails, check for dlopen in -ld
   if that fails AND host is mingw, modify CFLAGS to use internal dlfcn

Note that LDFLAGS modification should go AFTER (!) all AC_CHECK_LIB
calls, because -no-undefined is no longer valid as a compiler option.

[1] http://code.google.com/p/dlfcn-win32/
configure.ac