Thanks Konstantin. I think putting jemalloc early enough worked. But I am getting the following errors and it seems others have seen this error before . I am compiling with windriver toolchain. I ran the configure script, so I am wondering the configure script should have done the right thing and determined that all these definitions are already present and hence when generating the header file , should have skipped these definitions so that this is not an issue.
Do I need to pass specific options to configure or what is the right way to fix this issue ? declaration of 'void* malloc(size_t) throw ()' throws different exceptions jemalloc-3.6.0/include/jemalloc/jemalloc.h:137: error: from previous declaration 'void* malloc(size_t)' usr/include/stdlib.h:474: error: declaration of 'void* calloc(size_t, size_t) throw ()' throws different exceptions jemalloc-3.6.0/include/jemalloc/jemalloc.h:139: error: from previous declaration 'void* calloc(size_t, size_t)' usr/include/stdlib.h:486: error: declaration of 'void* realloc(void*, size_t) throw ()' throws different exceptions jemalloc-3.6.0/include/jemalloc/jemalloc.h:144: error: from previous declaration 'void* realloc(void*, size_t)' usr/include/stdlib.h:488: error: declaration of 'void free(void*) throw ()' throws different exceptions /include/jemalloc/jemalloc.h:145: error: from previous declaration 'void free(void*)' lib/gcc/i586-wrs-linux-gnu/4.3.2/../../../../i586-wrs-linux-gnu/include/c++/4.3.2/cstdlib:73, -----Original Message----- From: Konstantin Tokarev [mailto:annu...@yandex.ru] Sent: Monday, May 18, 2015 12:20 PM To: Mayank Kumar (mayankum); jemalloc-discuss@canonware.com Subject: Re: jemalloc linking 18.05.2015, 19:30, "Mayank Kumar (mayankum)" <mayan...@cisco.com>: > Hi All > > My application worked perfectly with LD_PRELOAD and the virtual memory growth > was contained. As soon as I linked it dynamically with jemalloc, this wasn’t > the case. So virtual memory kept growing. So I am guessing that my > application is still not using jemalloc but libc’s default malloc when > linking dynamically. My application is a binary which links to many > dynamically loadable libraries some of which are internally built and some > are open source versions which we don’t always build. My questions are:- > > 1. When linking dynamically with jemalloc, is it a requirement to have > –ljemalloc as early as possible or possibly the first library being linked > to, to override the default malloc ? Yes - this is how dynamic linking works on ELF platforms. When linker sees undefined symbol "malloc" it will take it from first ELF object (in order of specified ld arguments) which has defined "malloc" symbol. > > 2. What method does jemalloc uses while linking to override malloc, > does it use the malloc_hooks to override or just the normal linking, so that > whatever the linker gets first, it will link to . LD_PRELOAD deals only with ELF linking, injecting your library(ies) in the beginning of *.so list used by runtime linked (e.g., ld-linux.so) > > 3. Would linking statically solve this issue, although my preference > would be to link dynamically since I have at least 10 processes which needs > jemalloc, and at least they would share the code in memory. > > 4. When linking with external open source libraries, do I need to > re-compile those with jemalloc as well to make sure any mallocs in those > libraries also go through jemalloc or that is not required. I am guessing it > should not be required as long as my process links to the right malloc > library, their dependencies should be correctly resolved. -- Regards, Konstantin _______________________________________________ jemalloc-discuss mailing list jemalloc-discuss@canonware.com http://www.canonware.com/mailman/listinfo/jemalloc-discuss
