Re: Building GCC 4.6.x on Mac OS X

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 30 October 2011 21:10, Mihai Moldovan <ionic@ionic.de> wrote:
> * On 30.10.2011 09:56 PM, Jonathan Wakely wrote:
>> On 30 October 2011 20:42, Mihai Moldovan wrote:
>>> * On 30.10.2011 09:24 PM, Jonathan Wakely wrote:
>>>> On 30 October 2011 19:25, Mihai Moldovan wrote:
>>>>> As the first paste in http://trac.macports.org/ticket/27237#comment:14
>>>>> suggests (extracted from new_allocator.h:98), __p should be permitted to
>>>>> be a null pointer.. which... well, is clearly not the case here for some
>>>>> reason.
>>>> Calling delete on a null pointer is permitted, but passing a null
>>>> pointer to that allocator's deallocate function is not. ?Which is it?
>>> Did you have a look at the paste? new_allocator.h:98 is "{ ::operator
>>> delete(__p); }" which is the deallocate function, yep.
>> That's ok to call with a null pointer then, operator delete can be
>> called with a null pointer.
>>
>> From another trac comment:
>>
>> Breakpoint 9, std::string::assign (this=0x101777fa8, __str=<value
>> temporarily unavailable, due to optimizations>) at new_allocator.h:98
>> 98 ? ? ? ? ?{ ::operator delete(__p); }
>> (gdb) print __p
>> Cannot access memory at address 0x0
>>
>>
>> That doesn't look like __p is null to me, I would expect it to print
>> 0x0 for a null pointer:
>>
>> (gdb) print __p
>> $1 = 0x0
>
> Yeah, delete can be called on a null pointer, but free shouldn't, or am
> I messing something up?

No, free(0) isn't valid, but operator delete won't call free if the
pointer is null.

> On the other hand, why would free() crash if __p was not null? It may
> have been previously free'd but... I don't see that happening.

Really?
ld(39160) malloc: *** error for object 0x100285640: pointer being
freed was not allocated

That looks like an invalid pointer to me.

> Still, something weird is happening here and the GCC build system
> shouldn't try to use the new stdlibc++, I wonder why and how it tries to
> in the first place.

I don't understand what you mean, or what you mean by preloading in
the trac report.

If you're talking about DYLD_LIBRARY_PATH, I think that has to be set
while building the compiler, so the new libstdc++ is used by the new
compiler.

If ld can't be linked with your new libstdc++ then it is probably due
to an ABI compatibility. My guess would be something to do with
fully-dynamic-string but you claim that's being used correctly. How
was the system libstdc++ configured?  How are you configuring your gcc
builds?