[lxc-users] The purpose of init.lxc.static

[Serge Hallyn]

Quoting Leonid Isaev (lisaev at umail.iu.edu):
> On Wed, Jun 18, 2014 at 02:08:00PM +0000, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > 
> > > Sounds like we really want a way to detect that case and turn off
> > > building the static init in that case.
> > > 
> > > The reason for the static init is to make lxc-execute work in all cases,
> > > including cases where the host architecture doesn't match the
> > > container's and cases where the container doesn't run the same libc as
> > > the host (or doesn't have a libc at all).
> > > 
> > > LXC has fallback code to look for the dynamically linked init.lxc, so
> > > there's no reason why the static one would be an hard dependency.
> > > 
> > > Serge?
> > 
> > Well the -lcap we can fix easily, but no -lutil?  That's a bit messed
> > up.  So perhaps we should simply have configure.ac check for the static
> > libraries ahead of time.  If there is no AM_FOO for that we can do our
> > own quick test.
> > 
> > Leonid are you up writing such a patch?
> 
> Yes, if you can wait because I'll be travelling in the next 10 days and can not
> guarantee internet access. But I still don't fully understand which static libs
> we should check for -- only those above, or there are others planned in the
> future?
> 
> Wouldn't it be simpler to make a new ./configure option, e.g.
> "--disable-static-binaries" which disables the static build alltogether? So, by
> default we compile init.lxc.static (and possibly other tools in the future),
> just as before, and not break existing packaging workflows.
> 
> I know there's plenty of discussion how bad static linking is, but my primary
> objection against it is maintainability of packages. In Arch we have various
> tools to tell which binaries (and packages) link to a given library, so
> rebuilds are straightforward. With static binaries there is no way to tell and
> this might be a problem on a rolling release system where updates occur
> continuously.

Yes, we don't like it either, but it's the only straightforward way of
allowing lxc-execute in random containers without first setting up all of
the library dependencies.

Other ideas are definately welcome.  Including "but we don't really care
about that"