HI Jason, I'll see if I can use your idea for dynamically linking. There's a few libraries i would need to do this for but if I can sort this out it would be good. At the moment I have statically linked releases for a few different Linux builds. With regard the is_malloc(je_malloc), I tried commenting out the #if & #endif lines but the program still used glibc malloc, I guess this may be order of loading the libraries so I will try with jemalloc first. I'll let you know if that works. Thanks for your advice and help. Colin <div class="gmail_quote">On 20 July 2013 02:27, Jason Evans <<a href="mailto:jasone@canonware.com" target="_blank">jasone@canonware.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Jul 19, 2013, at 12:41 AM, Colin Hercus <<a href="mailto:colin@novocraft.com">colin@novocraft.com</a>> wrote: > I am trying to test a HPC appl'n with jemalloc to see if it can reduce memory fragmentation and slow memory growth of a long running multi-threaded app. > > This application is statically linked as it's not open source and we need one binary distribution to run on multiple Linux versions. > > If I configure jemalloc without a jemalloc prefix (je_) and link with -static -ljemalloc I get linker errors for multiply defined symbols > > g++ -m64 -Wl,--eh-frame-hdr -o ./bin/xxxx ./obj/xxxx.o ..... -static -pthread -lcrypto -lz -lbz2 -ldl -ljemalloc -lunwind -Wl,-Map=gccmaps/xxxx.map </div>There's a good chance that you can make the errors go away by putting -ljemalloc earlier in the link line. It looks to me like libcrypto is pulling in the glibc malloc symbols, and by the time the libjemalloc portion of linking occurs, it's too late for jemalloc to provide the symbols. That said, pure static linking is pretty perilous, and I recommend dynamically linking against the system libraries, and linking to static libraries by specifying e.g. libjemalloc_pic.a along with the .o object files (and/or .a archives) in your project. glibc in particular does an excellent job of maintaining symbol compatibility across many years of releases, so you can ship around a binary that is dynamically linked against glibc with fewer issues than you will run into with a statically linked-in glibc. glibc protects you from a rather unstable Linux kernel interface, and if you try to run your static binary on top of a substantially different kernel, hilarity will ensue. <div class="im"> > If I build with a prefix of je_ then linking is okay but memory allocation is via glibc malloc. The same is true if I dynamically link without a prefix. > > Is there any simple easy way to get je_malloc to hook itself in as a replacement for malloc the way tcmalloc does? </div>jemalloc *does* hook itself in as a replacement for glibc malloc, but only if no prefix is specified. =) You can make a one line change to src/jemalloc.c to unconditionally enable hooking. Replace: #if ((is_malloc(je_malloc) == 1) && defined(__GLIBC__) && !defined(__UCLIBC__)) with: #if 1 Jason</blockquote></div>