On 04/11/2011 01:29, Simon McVittie wrote: > On Thu, 03 Nov 2011 at 23:37:37 +0100, Dominic Fandrey wrote: >> On 03/11/2011 17:58, Simon McVittie wrote: >>> This change isn't right. libcurl.so is the development symlink for libcurl >>> [...] 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). >> >> That's rather strange. On FreeBSD the current version is libcurl.so.6. >> And the .so file always links to the currently installed version of the >> library. I always thought that was the normal way of things to be. > > FreeBSD libtool library versioning isn't quite the same as on Linux, > so it's not necessarily surprising that the current libcurl ends up with a > different SONAME for you (libtool treats the platforms differently) - it's > probably the same libcurl version under a different name. I believe the > general structure is the same, though. > > On Linux, at least, you typically have: > > libfoo.so.0.1.2 - real file, nothing should be using this name directly > > libfoo.so.0 - the name that gets written into binaries by the linker, > and hence the name that the binary needs to find on startup; > symlink to the real file > > ... > > The purpose of this is that you can have libfoo.so.0 and libfoo.so.1 > installed at the same time, to support a new executable that was compiled > against libfoo.so.1 and an older one compiled against libfoo.so.2 (but you > have to choose one or the other to compile new executables against, because > when you compile you just say "-lfoo" - the libfoo.so symlink points to that). > > Think of libfoo.so.0 as "libfoo.so, compatibility level 0".
Actually FreeBSD has symbol versioning, so you can contain all versions of a library in a single file. All this name play is not really necessary, it's just that FreeBSD is not the main target platform of most software in the world and we have to live with the baggage that brings us. >> I can see how an interface change could cause a crash, but I don't see >> how it can cause security issues. > > For instance, a typical ABI break that would result in a new SONAME is a > struct becoming larger (maybe struct foo in libfoo.so.0 is 20 bytes and > struct foo in libfoo.so.1 is 32 bytes). If you write a new struct with > partially attacker-controlled contents into a location only large enough > for the old struct, that's a stack or heap overflow, which could well be > exploitable (e.g. if it can overwrite the return address or a function > pointer). I didn't think of this, thanks for educating me! >> I see it doesn't work that way. Hard coding library versions doesn't sound >> like a very good idea to me, too, though. > > If you set USE_CURL_DLOPEN=0 the compiler will automatically pick up the > SONAME you compiled against, write it into the binary, and it'll work like > every other library (e.g. libjpeg, commonly seen with SONAME libjpeg.so.6 > or libjpeg.so.8). I'd recommend that for distribution packages - it's almost > certainly how every other executable in your distribution works. Surprisingly it doesn't link. I set USE_LOCAL_HEADERS=0 in order to unveil incompatibilities. Apparently the freebsd/libcurl.so.6 is in deed something other than debian/libcurl.so.4. That's a grep over the error messages: : undefined reference to `curl_easy_cleanup' : undefined reference to `curl_easy_getinfo' : undefined reference to `curl_easy_init' : undefined reference to `curl_easy_setopt' : undefined reference to `curl_easy_strerror' : undefined reference to `curl_multi_add_handle' : undefined reference to `curl_multi_cleanup' : undefined reference to `curl_multi_info_read' : undefined reference to `curl_multi_init' : undefined reference to `curl_multi_perform' : undefined reference to `curl_multi_remove_handle' : undefined reference to `curl_version' Not surprising, Debian has a reputation for being dated. One has to admire their effort of back porting bug fixes. But on FreeBSD we try to supply our users with the latest releases of a software for /all supported branches/ of the system. I.e. we trust the projects upstream to have a decent release cycle. That doesn't always work out, but I still like this approach. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ 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.
