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

[Leonid Isaev]

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.

Thanks,
L.
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140618/a6bfcac9/attachment.sig>