> On Nov. 17, 2014, 12:30 p.m., Dominic Hamon wrote: > > when we have the HTTP API, there will be no need for a shared libmesos. In > > fact, we're considering having wholly static slave and master executables > > to avoid some deployment issues we have with partial updates[1]. > > > > i understand this shrinks the final size, but we will probably end up > > undoing this at some point. > > > > 1. libmesos updates, mesos-fetcher gets the new one, slave still uses the > > old one. > > Cody Maloney wrote: > In the case you are describing, you wouldn't want a static libmesos or a > dynamic one ever. You build all of mesos as static libraries on a package > builder. So that would be you add a '--disable-shared' (AC_DISABLE_SHARED) to > the build as well as the AC_DISABLE_STATIC. In building mesos-master, > mesos-slave, the fetcher, etc. there isn't a need for libmesos at all, in > static or dynamic forms. Note you can still build the static library if you > are in one of the few environments that need it with --enable-static. > > For Mesos Modules, we will likely always need some form of libmesos.so > (Although the interfaces it exposes may be fairly different than those it > currently exposes). Unless we don't want parts of mesos to be shared to some > modules. > > I would also note you can still use libmesos.so and actually isolate the > SO's from eachother / make it so the Linux Dynamic Linker (ldd) doesn't > search in ways that could ever get multiple .so files so you can never get > partial updates. > > Cody Maloney wrote: > Parts of that didn't come out right... > > The core: > Static binaries for mesos-fetcher, mesos-master, mesos-slave, etc. don't > need libmesos.a. All those binaries are just linked with the code directly. > You would only need a libmesos.a if you are building an external project > which doesn't have pure bindings and trying to link it statically.
"""when we have the HTTP API, there will be no need for a shared libmesos. In fact, we're considering having wholly static slave and master executables to avoid some deployment issues we have with partial updates.""" Is there a jira ticket tracking this HTTP replacement for libmesos? - R.B. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28082/#review61755 ----------------------------------------------------------- On Nov. 14, 2014, 8:17 p.m., Cody Maloney wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28082/ > ----------------------------------------------------------- > > (Updated Nov. 14, 2014, 8:17 p.m.) > > > Review request for mesos and Timothy St. Clair. > > > Repository: mesos-git > > > Description > ------- > > Shrinks the size resulting from a 'make install' considerably. > > On a build with the options: > ../configure --enable-optimize build > > du -h of the install directory gives: > 52MB with patch > 113MB without patch > > Debug builds the difference will be even more noticeable. > > Distribution packaging guidelines for Debian, Fedora, and Ubuntu all remove > static libraries. In the few cases where someone needs a static library, it > is still buildable. Developers should be linking against the dynamic libmesos. > > The rest of the unnecessary size comes from 2 places > > - 22MB We effectively have two copies of libmesos (libmesos.so, and one in > the python native binding) > - 5-15MB We export all symbols in the .so, rather than just the necessary > ones (Combination of lots of extra strings in the binary, and excess > non-optimizable code). > > > Diffs > ----- > > configure.ac c287a17307fb821fc04ded67ff9f33d27947e5d7 > > Diff: https://reviews.apache.org/r/28082/diff/ > > > Testing > ------- > > Built and compared install directory sizes on local machine > Make distcheck on ubuntu 14.04 > > > Thanks, > > Cody Maloney > >
