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 Woodhouse Open 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]
