I think we should look into adopting "-fvisibility=hidden" and explicitly annotating the symbols that we want to export:
https://issues.apache.org/jira/browse/MESOS-6734 Although I agree this isn't a trivial change and it would be good to have some tool support here, but there are lots of benefits [1,2]. Neil [1] https://gcc.gnu.org/wiki/Visibility [2] https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf On Mon, Dec 12, 2016 at 2:17 PM, Joris Van Remoortere <jo...@mesosphere.io> wrote: > There are a significant number of developer and runtime performance > benefits from turning this flag on. > In my opinion it is also a dangerous flag to turn on by default without a > strict set of rules for our codebase to ensure that we don't accidentally: > > - have multiple instances of static variables when we think they are a > singleton > - run into inequality when we expect equality for comparison of in-lined > function pointers (For example when building a vtable in a library for > something like variant / visitor) > > Although the likelihood that our codebase would suffer from these is low, I > would prefer to have clang-tidy support and have some rule checkers to > ensure that we can turn this flag on by default and know we will catch any > future code that may break these rules. > > @James have you done any validation of the codebase and the libraries we > depend on to ensure this is safe? > > Joris > > — > *Joris Van Remoortere* > Mesosphere > > On Mon, Dec 5, 2016 at 1:16 PM, James Peach <jor...@gmail.com> wrote: > >> >> > On Dec 2, 2016, at 10:54 PM, Jie Yu <yujie....@gmail.com> wrote: >> > >> > Another tip. If you are on macOS sierra, you might notice the linking is >> > extremely slow using the default clang. >> > >> > Using CXXFLAGS `-fvisibility-inlines-hidden` will greatly speedup the >> > linking. >> >> Is there a reason we should not always do this? It reduces the number of >> exported symbols in libmesos.so from 250K to 100K. >> >> J
