[Gc] Status of gc on Mac OS X - gc_cpp issue
skaller at users.sourceforge.net
Thu Oct 5 08:40:57 PDT 2006
On Thu, 2006-10-05 at 14:48 +0200, Renaud Blanch wrote:
> After further investigation, this is an issue with shared library
> Linking with gc shared libraries does not override the default
> delete, whereas linking statically does.
> For example :
> g++ -o test_cpp tests/test_cpp.o -lgc -lgccpp -L./.libs
> does not intercept delete but
> g++ -o test_cpp tests/test_cpp.o .libs/libgc.a .libs/libgccpp.a
> works fine.
> Maybe this should be reported as a gcc bug ?
> I have not been able to find a workaround this, even using the
> LD_PRELOAD environment variable.
Hmm ... option to ld, no idea if this will help ..
Use a wrapper function for symbol. Any undefined reference to sym‐
bol will be resolved to "__wrap_symbol". Any undefined reference
to "__real_symbol" will be resolved to symbol.
This can be used to provide a wrapper for a system function. The
wrapper function should be called "__wrap_symbol". If it wishes to
call the system function, it should call "__real_symbol".
Here is a trivial example:
__wrap_malloc (size_t c)
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
If you link other code with this file using --wrap malloc, then all
calls to "malloc" will call the function "__wrap_malloc" instead.
The call to "__real_malloc" in "__wrap_malloc" will call the real
You may wish to provide a "__real_malloc" function as well, so that
links without the --wrap option will succeed. If you do this, you
should not put the definition of "__real_malloc" in the same file
as "__wrap_malloc"; if you do, the assembler may resolve the call
before the linker has a chance to wrap it to "malloc".
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: https://felix.sf.net
More information about the Gc