Re: [PATCH] Slightly better way to __USE_MALLOC

[Brad Spencer <spencer at infointeractive dot com>]

On Thu, Oct 10, 2002 at 01:17:34PM -0500, Benjamin Kosnik wrote:
> > I was able to reproduce the problem after all.  The goal has to be to
> > emit an undefined symbol into every object file that "tags" it as
> > being compiled against one or the other ABI.  I'm trying to work out
> > different ways to do this and then choose the one with the minimal
> > side effects (i.e. runtime cost, etc).
> 
> We already have symbol versioning that does this. You don't need another
> mechanism.
> 
> I don't understand why this isn't much simpler. 

I think it is much simpler.  I was vaguely aware of symbol versioning,
but the dummy.map file led me to think that it can be turned off, and
I wasn't sure if that was okay.  If it is, that's great!

> I'd think you can just go ahead with the plot to have both allocators
> available all the time. Add both the malloc_alloc_template, and the
> pool_alloc_template instantiations. These new symbols can be put into
> the GLIBCPP_3.2.1 version, or GLIBCPP_3.3, so that linkage is
> versioned.

I agree that they can both be available all the time, but the default
allocator used by the STL containers can only be one of them.  To me,
there is value in being able to swap the malloc-based allocator in
underneath everything, even if it means I have to recompile all
application code.  I don't think it's possible to do things as
efficiently and not have to recompile.

I will learn how symbol versioning works.  Thanks for the help!

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company