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

Serge Hallyn serge.hallyn at ubuntu.com
Wed Jun 18 19:13:52 UTC 2014


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"


More information about the lxc-users mailing list