On Wed, Jun 18, 2014 at 07:13:52PM +0000, Serge Hallyn wrote: > Quoting Leonid Isaev ([email protected]): > > On Wed, Jun 18, 2014 at 02:08:00PM +0000, Serge Hallyn wrote: > > > Quoting Stéphane Graber ([email protected]): > > > > > > > > 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"
I think it's fine so long as we keep things small and simple, so drop any external dependency outside of libc (as was suggested a few times, the libcap one doesn't make much sense there) and have a configure flag (with reasonable auto-detect) to turn the feature on/off. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
