OpenConnect 9.01 does not work under Ubuntu 20.04

Luca Boccassi bluca at
Wed May 4 11:19:46 PDT 2022

On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote:
> On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote:
> > 
> > The same can be done by maintaining a symbols file. I do that for the
> > actual Debian/Ubuntu builds (
> >
> > ), but it's a _lot_ of work and it would constantly break the builds
> > as new things are added/removed, so I did not add it to the upstream
> > builds.
> It shouldn't break the build as things are added; surely that's the
> point? 

I'm quite sure it's flagged as an error by Lintian if there's a symbol
missing in the list.

> It *should* break the build if things are removed without bumping the
> soname. Which is also the point :)
> But I don't really understand why Debian lists each individual symbol.
> The library *minor* version really ought to be enough for any even
> semi-sanely-maintained library. And if the library is *so* badly
> maintained that it isn't enough, all bets are off anyway; the developer
> might even break binary ABI between versions *without* changing symbol
> names or version, surely?

I'm not sure why the tooling works the way it does, maybe historical
reasons, it's ancient stuff.

> Anyway, for OpenConnect this script ought to be able to build the
> symbols file from openconnect.h, which does have a history of when each
> symbol was added:

It would have to be ran manually every time. I'm not sure it's worth
the hassle, for this setup? Is there any issue with lock-step updates?

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the openconnect-devel mailing list