On Thu, 03 Nov 2011 at 10:14:35 +0100, Dominic Fandrey wrote:
> --- code/client/cl_curl.h.orig 2011-11-03 09:57:21.000000000 +0100
> +++ code/client/cl_curl.h 2011-11-03 09:57:34.000000000 +0100
> @@ -40,8 +40,7 @@
> #elif defined(MACOS_X)
> #define DEFAULT_CURL_LIB "libcurl.dylib"
> #else
> - #define DEFAULT_CURL_LIB "libcurl.so.4"
> - #define ALTERNATE_CURL_LIB "libcurl.so.3"
> + #define DEFAULT_CURL_LIB "libcurl.so"
> #endif
This change isn't right. libcurl.so is the development symlink for libcurl:
on a dpkg- or RPM-based system it'll only be present if you have libcurl
development files (libcurl-dev, curl-devel or whatever). Non-developer systems
should only have the symlink named after the SONAME (libcurl.so.4 or
libcurl.so.3), and the real file that the symlinks point to (libcurl.so.4.2.0
or whatever).
Allowing more than one SONAME of libcurl to be loaded is rather suspicious -
the whole point of a SONAME is that libfoo.so.0 and libfoo.so.1 are not
compatible, so if your binary was compiled against one particular SONAME,
you should only be using that SONAME at runtime (and using the wrong one
could lead to a crash or even a security vulnerability).
However, Debian/Ubuntu seem to have a symlink libcurl.so.3 -> libcurl.so.4,
which suggests that those two libraries are in fact compatible, and the
SONAME was bumped unnecessarily.
I personally think ioquake3 should just link against its libraries in the
normal way, making them hard dependencies for the binary - it currently does
this for everything except curl and openal. curl and openal are dlopen()ed,
for whatever reason, although this can be turned off at compile time using
USE_CURL_DLOPEN=0 and USE_OPENAL_DLOPEN=0 - which is how we compile it in
Debian/Ubuntu, and I suspect Hans does the same in Fedora. Distributions
have a lot of experience in dealing with this sort of library dependency
and turning them into package dependencies automatically.
S
_______________________________________________
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.
