Re: [PATCH] Slightly better way to __USE_MALLOC

[Brad Spencer <spencer at infointeractive dot com>]

On Thu, Oct 10, 2002 at 05:46:08PM -0500, Loren James Rittle wrote:
> OK, you said that you had an example, but this is exactly what we want
> to avoid (by catching at compile-time):

Yes.  Using your example specifically, here's what I have working
currently in my testbed.  Please excuse the long paths.

eng-linux1:/build/eng-linux1/spencer/gcc-cross/test/loren$ cat a.cc
//a.C
#include <list>

void foo (std::list<int>& a)
{
  a.pop_back ();
}

eng-linux1:/build/eng-linux1/spencer/gcc-cross/test/loren$ cat b.cc
//b.C
#include <list>

void foo (std::list<int>& a);

int main (void)
{
  std::list<int> a;

  a.push_back (1);

  foo (a);
}

The library is built with the default pool allocator:

$ nm --defined-only
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/lib/libstdc++.a
|grep __node_allocator_is
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/lib/libstdc++.a:stl-inst.o:00000000
R std::__node_allocator_is_default_alloc_template

Link error when either object doesn't define the macro properly (look
for the "__node_allocator_is" lines):

eng-linux1:/build/eng-linux1/spencer/gcc-cross/test/loren$
CXX=/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ make
clean all BREAK_IT=1 FILE_TO_BREAK=a
rm -f a.o b.o loren
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
-D_GLIBCPP_USE_MALLOC=1 -c -o a.o a.cc
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
-c -o b.o b.cc
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
-o loren a.o b.o
a.o(.data+0x0): undefined reference to
`std::__node_allocator_is_malloc_alloc_template'
collect2: ld returned 1 exit status
make: *** [loren] Error 1

eng-linux1:/build/eng-linux1/spencer/gcc-cross/test/loren$
CXX=/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ make
clean all BREAK_IT=1 FILE_TO_BREAK=b
rm -f a.o b.o loren
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
  -c -o a.o a.cc
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
-D_GLIBCPP_USE_MALLOC=1 -c -o b.o b.cc
/build/eng-linux1/spencer/test-gcc/i686-pc-linux-gnu/bin/g++ -Wall -O2
-o loren a.o b.o
b.o: In function `main':
b.o(.text+0x88): undefined reference to
`std::__malloc_alloc_template<(int)0>::_S_oom_malloc(unsigned)'
b.o(.data+0x0): undefined reference to
`std::__node_allocator_is_malloc_alloc_template'
b.o: In function `std::list<int, std::allocator<int>
>::insert(std::_List_iterator<int, int&, int*>, int const&)':
b.o(.gnu.linkonce.t._ZNSt4listIiSaIiEE6insertESt14_List_iteratorIiRiPiERKi+0x61):
undefined reference to
`std::__malloc_alloc_template<(int)0>::_S_oom_malloc(unsigned)'
collect2: ld returned 1 exit status
make: *** [loren] Error 1

And likewise when the library is build to use malloc (although
c++config defines the macro and you have to go out of your way to make
it not do that.  I'm simulating the condition where the headers are
installed once, but a malloc-using library is being pulled in, like I
described in my original message).  Only objects that also used malloc
will link.   

I've attached the diff in its current state for reference.  I'm now
basing this off the trunk CVS version instead of gcc-3.2.

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

Attachment: enable-pool-allocator-v1.patch
Description: Text document