[Gc] GC and dynamic libraries

Andrew Begel abegel at eecs.berkeley.edu
Mon Jun 28 00:08:48 PDT 2004


On some platforms, we've found that linking the .o's in the shared 
library into their own .o file with -nostdlib and on Linux -Wl,-r 
-Wl,--whole-archive (*.o that want to be in the shared library) 
-Wl,--no-whole-archive, and then linked the result into a shared 
library via -shared flag, you should be able to properly override new 
and delete. This is how we do it in our project (though we did recently 
switch from new_gc_alloc.h to gc_alloc.h without too much hardship).

Also remember if you're loading this gc-enabled shared library from 
some other non-gc-aware application, you'll need to set 
LD_PRELOAD=/path/to/gc/library/libgc.so before starting the 
application, otherwise some threads won't get properly registered for 
later GC in the shared library.

Andrew




On Jun 23, 2004, at 8:26 AM, Joris van der Hoeven wrote:

>
> Hi,
>
> In despair, I continued to try making the STL use GC,
> even though this might not be the source of my problems.
> I hope that there is a systematic way to do use GC
> in combination with the STL. What about the following code:
>
> #ifdef SUPPORTS_GC
> #include <gc/new_gc_alloc.h>
> #include <new>
> inline void* operator new(std::size_t sz) throw (std::bad_alloc) { 
> return GC_MALLOC (sz); }
> inline void* operator new[](std::size_t sz) throw (std::bad_alloc) { 
> return GC_MALLOC (sz); }
> inline void operator delete(void*) throw() {}
> inline void operator delete[](void*) throw() {}
> inline void* operator new(std::size_t sz, const std::nothrow_t& dummy) 
> throw() {return GC_MALLOC (sz); }
> inline void* operator new[](std::size_t sz, const std::nothrow_t& 
> dummy) throw() { return GC_MALLOC (sz); }
> inline void operator delete(void*, const std::nothrow_t& dummy) 
> throw() {}
> inline void operator delete[](void*, const std::nothrow_t& dummy) 
> throw() {}
> #endif
>
> Unfortunately, this still does not work with dynamic libraries...
>
> As I mentioned in my previous email, malloc never seems to be called 
> though,
> so it is very plausable that my problems actually do not stem from the 
> STL,
> but from GC itself.
>
> Best wishes, Joris
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list