[Gc] Status of gc on Mac OS X - gc_cpp issue
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/
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
>> 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
> 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++: http://felix.sf.net
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc