Ok, a slightly different new operator declaration defeated my global search. I just committed a fix for the RexxMemory problem. I think that get's all of the problem places.
Rick On Thu, Sep 23, 2010 at 7:58 AM, Manfred Lotz <[email protected]> wrote: > On Thu, 23 Sep 2010 07:07:58 -0400 > Rick McGuire <[email protected]> wrote: > >> I just took another look at this, and found a description of the >> problem that gave me more information on what the root cause of the >> error. This problem appears to be much less pervasive than I >> originally suspected. I committed a change to trunk that I *think* >> will correct this, but I don't have access to a system with that >> compiler level on it to see if things will compile cleanly now. If >> anybody can verify that this fixes the problem, then we probably >> should include this in the 4.1.0 release. >> >> Rick >> > > > I had a couple of minutes to try it out before my next meeting. > Checking out 6218 and doing bootstrap, autoconf, configure and make I > got the same error but at a different point: > > > > libtool: compile: g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=2 > -DORX_MOD=0 -DORX_FIX=0 -DORX_SYS_STR=\"LINUX\" > -DORX_CATDIR=\"/usr/bin\" -DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib > -I./api -I./api/platform/unix -I./common -I./common/platform/unix > -I./interpreter -I./interpreter/behaviour -I./interpreter/execution > -I./interpreter/memory -I./interpreter/package > -I./interpreter/concurrency -I./interpreter/expression > -I./interpreter/instructions -I./interpreter/classes > -I./interpreter/classes/support -I./interpreter/runtime > -I./interpreter/parser -I./interpreter/messages > -I./interpreter/streamLibrary -I./interpreter/platform/common > -I./interpreter/platform/unix -g -O2 -g -O2 -Wall -funsigned-char > -Wpointer-arith -Wcast-qual -Wcast-align -Wshadow -Wwrite-strings > -D__cplusplus -Wredundant-decls -DNOOPT -DPTHREAD_KERNEL > -D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DLINUX -DOPSYS_LINUX -MT > librexx_la-MemorySupport.lo -MD -MP > -MF .deps/librexx_la-MemorySupport.Tpo > -c ./interpreter/platform/unix/MemorySupport.cpp -fPIC -DPIC > -o .libs/librexx_la-MemorySupport.o ./interpreter/memory/RexxMemory.hpp: > In member function 'MemorySegment* > MemorySegmentPool::newSegment(size_t)': > ./interpreter/memory/RexxMemory.hpp:149:19: > error: non-placement deallocation function 'static void > MemorySegmentPool::operator delete(void*, > size_t)' ./interpreter/platform/unix/MemorySupport.cpp:215:33: error: > selected for placement delete ./interpreter/memory/RexxMemory.hpp: In > member function 'MemorySegment* > MemorySegmentPool::newLargeSegment(size_t)': > ./interpreter/memory/RexxMemory.hpp:149:19: > error: non-placement deallocation function 'static void > MemorySegmentPool::operator delete(void*, > size_t)' ./interpreter/platform/unix/MemorySupport.cpp:263:33: error: > selected for placement delete make: *** [librexx_la-MemorySupport.lo] > Error 1 > > > So it seems to work...!? > > > > -- > Manfred > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
