Re: Building OpenConnect with libintl
On 2012/11/13 08:01, Woodhouse, David wrote: > On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: > > > > 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. > > I've committed a patch to make it use -version-info on OpenBSD, and > -version-number with GNU libtool. They seem to do the same thing, taking > the sane ABI-version numbers that I give them, and putting them directly > in the filename of the resulting library. > > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/ada3dea0 > > I note you don't seem to have an soname — so if I add functions to > libopenconnect and bump the minor release number, I think your GNOME and > KDE authentication dialogs for the VPN are going to break. If you update > OpenConnect and not rebuild those, of course. I appreciate you say you > don't. But OpenConnect might occasionally have required security or > compatibility upgrades, so users might want to. If people are installing software from packages, realistically they're going to have to follow packages for updates too - the package build infrastructure takes control of version numbers and enforces our own version numbers, so somebody building an updated OpenConnect themselves would need to update anything depending on it themselves (your major version number is beyond the one in packages, we start from 0.0 when something is first added to ports, largely as a check to ensure that the build infrastructure does handle overriding version numbers). Also besides changes in the packaged software itself triggering a version bump, sometimes we need to force libraries to get updated due to changes in the OS (very rare but occasionally necessary). The package tools keep track of library dependencies (rather than just package dependencies) and know that they need to update all depending ports if a lbrary is updated (and keep old libraries around in cases where not everything can be updated together). Unfortunately for every project like OpenConnect where developers are clear about how versioning works, there are probably 2 or 3 who don't, we do go as far as diffing source trees when updating to make sure we bump when needed and find that either bumps gets missed very often, or people just don't understand the rules at all (probably the most common error being projects which use their release version number for the library version irrespective of symbol changes). Within the patch branch for a stable release, we will backport important changes (manpower dependent..) if they don't break ABI, this does restrict what we can pull back a bit, however as our release cycles are fairly short (fixed six-monthly) this generally isn't a big problem in practice. (As far as the GNOME/KDE authentication goes, I believe this is via NetworkManager which we don't package at all, so I don't think this is going to affect us at present; I'm not sure of the current status of NM, but historically the HAL dependency made it too difficult). > Does that mean I should actually make it just '-version-info @APIMAJOR@' > and drop the ':@APIMINOR@' part for OpenBSD? I think it would make sense to keep both..
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: > > 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. I've committed a patch to make it use -version-info on OpenBSD, and -version-number with GNU libtool. They seem to do the same thing, taking the sane ABI-version numbers that I give them, and putting them directly in the filename of the resulting library. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/ada3dea0 I note you don't seem to have an soname â so if I add functions to libopenconnect and bump the minor release number, I think your GNOME and KDE authentication dialogs for the VPN are going to break. If you update OpenConnect and not rebuild those, of course. I appreciate you say you don't. But OpenConnect might occasionally have required security or compatibility upgrades, so users might want to. Does that mean I should actually make it just '-version-info @APIMAJOR@' and drop the ':@APIMINOR@' part for OpenBSD? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: > 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. That's exactly what '-version-number' does. While '-version-info' plays fucked-up games with arithmetic on the numbers you give it, the "deprecated" '-version-number' just puts the arguments straight into the filename/soname as $DEITY intended. It looks like your -version-info in OpenBSD libtool is actually doing what GNU libtool's -version-number option does? -- dwmw2 [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Fri, Nov 09, 2012 at 10:25:36AM +, Woodhouse, David wrote: > On Fri, 2012-11-09 at 11:17 +0100, Marc Espie wrote: > > On Thu, Nov 08, 2012 at 03:38:18PM +, 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.
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 11:17 +0100, Marc Espie wrote: > On Thu, Nov 08, 2012 at 03:38:18PM +, 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? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 03:38:18PM +, 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 :)
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 03:38:18PM +, 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? Found this in the GNU libtool documentation: "New projects should use the -version-info flag instead." It looks like -version-number is an accepted option (thus no error message), but no further processing is done on it. May be an oversight in our libtool? Note that the ports system overrides the version specified on the command line, to fit into the OpenBSD-specific versioning scheme. > > -- >Sent with MeeGo's ActiveSync support. > > David WoodhouseOpen Source Technology Centre > david.woodho...@intel.com Intel Corporation > > [demime 1.01d removed an attachment of type application/x-pkcs7-signature > which had a name of smime.p7s]
Re: Building OpenConnect with libintl
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? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
Woodhouse, David wrote: > It seems that libintl *is* present, but it's installed in /usr/local and > the compiler doesn't find it by default. [...] > surely I shouldn't have to advise users to build things that way when > using the platform's stock libintl? I would like to clarify that libintl is NOT part of a stock OpenBSD installation. It's third-party software and needs to be explicitly added as a package. (Well, most likely you add something else and it will pull in libintl as a dependency.) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Building OpenConnect with libintl
On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote:
> Pass LIBTOOL=/usr/bin/libtool on make's command line.
Thanks, that works. This commit should make it work for everyone
automatically, without them having to override it manually:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/8e2a463043
Now it should build out-of-the-box even when there's already a version
installed. It doesn't get NLS support unless you manually add /usr/local
to the compiler's search paths, but I'm prepared not to care about that
if that's what's expected on OpenBSD. I don't think it's sane for me to
*automatically* try adding /usr/local/{include,lib} on OpenBSD, is it?
I don't quite understand why that isn't the native toolchain default,
but it's not for me to fix it up in my own autohell. I have enough hell
of my own in there, without dealing with yours :)
Thanks for the help.
--
Sent with MeeGo's ActiveSync support.
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
[demime 1.01d removed an attachment of type application/x-pkcs7-signature which
had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 01:27:31PM +, Woodhouse, David wrote: > On Thu, 2012-11-08 at 14:06 +0100, Marc Espie wrote: > > *our* libtool looks first under .libs. If it doesn't, that's a bug. > > I surmise the bug-reporter is actually using gnu-libtool, or the > > libtool generated by THAT software. > > Hm, yes. I am *indeed* using GNU libtool. That's confusing; I didn't > even know it was installed. If I run 'libtool --version', I get the > non-GNU one. But "./libtool" in my build directory ??? built from the git > tree with libtoolize on the OpenBSD system, not from a tarball which > obviously would have its own pre-autotoolised stuff ??? is the GNU one. > > So perhaps the next question is: what's wrong with my ./autogen.sh > script? It currently looks like this: > > #!/bin/sh > > aclocal && \ > libtoolize --automake --copy --force && \ > automake --foreign --add-missing && \ > autoconf > > Should it have some kind of special case for OpenBSD? It looks like > 'libtoolize' on my default path is the GNU one, while 'libtool' isn't. I > don't think I did anything to screw with that; this should be a simple > OpenBSD 5.2 install. > > And even if I fix the autogen.sh script for people building from the git > tree, what about tarball releases that I make? Do I just let people know > that those are *broken* on OpenBSD because GNU libtool doesn't work > there? > > Confused... and hating autohell a little more than I did yesterday. > Which I didn't know was possible. 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".
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 12:57:42PM +, Stuart Henderson wrote: > > Anyway, it doesn't *work* either ??? the build failed. It seems that when > > building the openconnect executable, it finds the old libopenconnect.so > > in /usr/local/lib *before* the new one it's just built in the build > > directory. And thus the link fails. That sounds like it might be a > > libtool/autotools bug ??? surely it should link against the library it > > just built, and put -L./.libs on the search path *before* anything else? > > I was using the latest available tools where given the choice; autoconf > > 2.69, automake 1.12 and libtool (not GNU libtool) 1.5.26. Should I try > > with GNU libtool instead? > > > > I assume I'm doing something wrong here. Advice on how to make it build > > properly on OpenBSD would be much appreciated... > > libtool people: is there something we should be doing something to > reorder the library directory list to ensure the .libs directory > comes first in the search list? Or is there something else going on > here? We have some places in the ports tree where we explicitly override > LDFLAGS to include .libs directories (e.g. imagemagick) which I presume > is for this same reason - there aren't very many instances of this though > it's possible people have only worked-around this problem in cases > where they found it really painful to uninstall an existing package > and its dependencies when working on an update. *our* libtool looks first under .libs. If it doesn't, that's a bug. I surmise the bug-reporter is actually using gnu-libtool, or the libtool generated by THAT software. There's totally nothing we can do about gnu libtool, it is broken by design on anything that's not standard linux elf linking (and we're not, we treat libraries as specific objects, and don't really support linking stuff with libiconv.so)... fixing THAT upstream is really tiresome, because most of the FSF upstream guys will only cringe, tell us we should "conform", and not change anything in their way of thinking/doing things (we probably don't follow some writ of Saint Stallman, god preserve us).
Re: Building OpenConnect with libintl
On 2012/11/08 11:23, Woodhouse, David wrote: > I saw the OpenBSD 5.2 release and figured I should make sure the > OpenConnect VPN client builds OK on it still. It does, but I noticed > that it didn't build with localisation support, and tried to fix that. > > It seems that libintl *is* present, but it's installed in /usr/local and > the compiler doesn't find it by default. I'm not entirely sure if this > is a bug in the libintl/gettext installation, in the compiler default > search paths, or a deliberate design decision that an installed library > should fail to work by default... but I attempted to work around it by > adding 'CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' to my > configure invocation. That's tolerable for a first test build, but > surely I shouldn't have to advise users to build things that way when > using the platform's stock libintl? It's deliberate that the system preprocesser and linker don't search /usr/local/include and /usr/local/lib, I'm not sure of the original reasoning behind it. The usual method is exactly what you've done with the explicit LDFLAGS/CPPFLAGS and this is afaik standard behaviour on BSDs. When pkg-config is used there's generally no problem but this doesn't help with the very common libintl. > (I also needed to explicitly link against -liconv in addition to -lintl, > which I've now added to the configure script in git.) > > Anyway, it doesn't *work* either — the build failed. It seems that when > building the openconnect executable, it finds the old libopenconnect.so > in /usr/local/lib *before* the new one it's just built in the build > directory. And thus the link fails. That sounds like it might be a > libtool/autotools bug — surely it should link against the library it > just built, and put -L./.libs on the search path *before* anything else? > I was using the latest available tools where given the choice; autoconf > 2.69, automake 1.12 and libtool (not GNU libtool) 1.5.26. Should I try > with GNU libtool instead? > > I assume I'm doing something wrong here. Advice on how to make it build > properly on OpenBSD would be much appreciated... libtool people: is there something we should be doing something to reorder the library directory list to ensure the .libs directory comes first in the search list? Or is there something else going on here? We have some places in the ports tree where we explicitly override LDFLAGS to include .libs directories (e.g. imagemagick) which I presume is for this same reason - there aren't very many instances of this though it's possible people have only worked-around this problem in cases where they found it really painful to uninstall an existing package and its dependencies when working on an update.
