On Fri, Nov 09, 2012 at 10:25:36AM +0000, Woodhouse, David wrote: > On Fri, 2012-11-09 at 11:17 +0100, Marc Espie wrote: > > On Thu, Nov 08, 2012 at 03:38:18PM +0000, Woodhouse, David wrote: > > > On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: > > > > > > > > Pass LIBTOOL=/usr/bin/libtool on make's command line. > > > > > > > > Trying to get through the spaghetti of gnu autocrap only leads to > > > > insanity. > > > > > > > > That falls under the "don't fight that shit, it's hopeless". > > > > > > Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number > > > 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of > > > 'libopenconnect.so.2.1'. > > > > > > Should I be specifying that differently? > > > > > > > I should specify we don't even try to implement that "old" option, or > figure > > out how to do so :) > > Thanks. I note that '-version-info 2:1' seems to do different things for > OpenBSD vs. GNU libtool. On OpenBSD it gives me 'libopenconnect.so.2.1' > as I expect, but GNU libtool on Linux gives 'libopenconnect.so.2.0.1'. > > Did I mention that I hate autocrap?
Well, don't get me started on the usual rant, but basically, most upstream vendors don't understand ABIs. autocrap is part of the problem, not the solution. Their documentation concerning version numbering, and all the fuzz they add around it don't help at all. The "old" style (major.minor) is fairly simple to understand and to use, actually, as long as you don't try to play fucked up games with it. Unfortunately: - most devs out there are morons. - there's enough commercial pressure in the linux world that they push too hard not to break binary compatibility (which often leads to disaster because it's WAYS too easy to break binary compatibility and not notice unless you have the exact mix&match that breaks). symbol-versioning adds yet another hard-to-understand, deadly-when-you-get-it-wrong layer. Our libtools, both the one in base, and the gnu libtool port, cmake, and other build systems, have hooks to allow the system developer to *completely* override the upstream vendor ABI settings. For at least 3 reasons: 1/ a lot of upstream vendors are morons, and will bump library numbers based on "release" and don't look at the actual API. 2/ even with those that understand API, a lot don't understand ABI, and still will not bump when a critical data structure in their library undergoes a major change. 3/ even in the cases where upstream vendors DO care and understand, we still need to take control. Specifically, because we DO break our system ABIs regularly, and so, when you change the compiler, or a critical data structure in libc, the only way you can avoid a flag day is by bumping EVERY single library that uses those structures.... I was personally responsible for two of these, back when I was hacking on locale and we discovered we *had* to change FILE* to go forward, and back when we unified our C/C++ type systems so that size_t would alias to the same unsigned type everywhere... if you know C++'s ABI, C++ will encode every parameter and return type name into its symbols, after reducing them to their primitive type, so *every* library that referenced size_t had to be bumped... This is something critical to OpenBSD: we don't have enough manpower to do otherwise. An OpenBSD release has a shelf-life of one year, and the only way we manage to go forward is by keeping the base system and the ports tree in-synch. Compared to some other systems, we are very aggressive at removing old features and using new stuff right away.
