> Precisely, however, at least on Solaris and Linux (and I presume OSX also) > you can link with tcmalloc at build time, thus avoiding use of LD_PRELOAD > at all. > > So, normally (sans libtool and all that cruft), you would link an > application as follows: > > cc -o app app.o -lzmq > > If instead you do > > cc -o app app.o -lzmq -ltcmalloc > > Then bingo, your application will use tcmalloc. No brittleness at all.
OSX uses “two-level namespaces”, which breaks this. When the linker resolves a symbol, it records which library it found the symbol in, and will always use that library at runtime. So this example will make the allocations in app.c use tcmalloc, but *not* the allocations in zmq. You have to also link with tcmalloc when you compile zmq itself. You can turn off two-level namespaces at runtime, but then you have the error I mentioned earlier, where the runtime linker itself allocates some memory using the standard malloc, before switching all of the symbols over to tcmalloc. In this case, it's definitely an annoying feature to have to work around — but it's not really a “bug” per se, that we can ask Apple to fix — it's how they've chosen to design their linker. > Martin, maybe all we need to do is document this prominently in the FAQ? It > is a *much less invasive and complex* solution than adding custom > allocators to 0mq! Less invasive to whom? For the people working on zmq internals, you just have to train yourself to write zmq_malloc instead of malloc. For the people using zmq, there are two extra parameters to zmq_init, which you can leave as NULL if you want the default system allocator. I guess it's a matter of taste. There's a specific behavior I need to achieve: use a different allocator than the one provided by system. Personally, I'd rather be able to express this behavior directly in the code itself, rather than having to play games with the linker to make it happen. –doug
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
