[Gc] Status of gc on Mac OS X - gc_cpp issue

Andrew Begel abegel at eecs.berkeley.edu
Thu Oct 5 10:01:02 PDT 2006

It's not a bug. new and delete are not overrideable on MacOSX without  
a little extra work (this behavior, btw is part of the C++ spec.  
You're allowed to override everything but new and delete). In the  
source code for the Harmonia project you can see how we did it:  

I'll sketch out the idea here.

Create your overrides for new and delete. Mark them  
__private_extern__. Compile it into a static library (e.g.  
liballoc.a). If you can't mess up your source code with that  
qualifier, run nmedit -p liballoc.a to convert the symbols inside to  
private extern. This makes them not get exported outside of libraries  
that they might be linked into.

When you compile your code, compile against your overridden new and  
delete as you normally would, by including the header with the  
overrides. Then when you link your shared library, do this:

g++ -Wl,-r -o libsharedlib.o -all_load -notstdlib first.o second.o  


g++ -dynamiclib -o libsharedlib.dylib libshared.o liballoc.a -L/usr/ 
lib/bw-gc -lgc

The first link line creates a new .o file with no C++ lib linked in.  
That means no competition for the new and delete coming from  
liballoc.a. Making a .o makes sure that the free symbols new and  
delete are bound before you try to get them into a shared library.

The second link line creates the shared library you really wanted to  
make, but links in the new .o you built, and the liballoc.a to catch  
any references to new and delete from other libraries you may also be  
linking in. Note this final dylib *does* contain references to the C+ 
+ library. Marking new and delete overrides private extern makes sure  
that the symbols from liballoc.a do not conflict with those from the C 
++ lib for clients of the libsharedlib.dylib.

Repeat these steps for any code that needs the overridden new and  
delete, but only for code where the override needs to occur. If you  
merely link against these libraries but don't call new or delete in  
your own code, then you don't need to do it.


On Oct 5, 2006, at 8:40 AM, skaller wrote:

> On Thu, 2006-10-05 at 14:48 +0200, Renaud Blanch wrote:
>> After further investigation, this is an issue with shared library
>> support.
>> 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 ..
>  --wrap symbol
>   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:
>                    void *
>                    __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
>   "malloc" function.
>   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
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list