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 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? -- 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
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]
Building OpenConnect with libintl
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? (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... -- 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]
