Building GCC 4.6.x on Mac OS X

Building GCC 4.6.x on Mac OS X

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]

Hi all,

I've been trying to build GCC 4.6.x on Mac OS X to no avail (with 0 < x
< 3).

For easier understanding and pasting, I'd like to cross-link this thread
with http://trac.macports.org/ticket/27237 .
Please note, that I will give you links to the specific output snippets.

When building GCC 4.6.x, bootstrapping seems to work fine. However,
building libssp with the new xgcc (i.e. the one compiled with the
bootstrapped xgcc), configure is failing. Note that where exactly it
fails is not that important, but rather why. Please have a look at the
first paste in http://trac.macports.org/ticket/27237#comment:13 .
Clearly, the linker ld is crashing.

The second paste reveals, that it actually crashes while running the
delete operator on a basic_string and in turn using free() on the given
pointer. I debugged this using gdb (replaced ld with a script calling
ld.orig and sending SIGSTOP immediatly in order to be able to attach
gdb), finding out, that the given pointer __p is null/0x0.

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.

I then tried recreating the problem manually. In the second paste you
can see the used conftest.c file and the third paste is denoting the
used command line for compiling conftest.
However, when running it as-is, everything works beautifully.
Having a look at the ld binary, it's obvious that Apple compiled it
using clang and it's dynamically linking to the system libstdc++.dylib
(see paste four.)

Now, due to the fact that running xgcc/ld without any modifications
works fine and ld doesn't crash, maybe the build system tries to preload
the recently built new libstdc++.

Trying that using the command line given in the fifth paste, I was able
to make ld crash at exactly the same point.

My assumption is that the build system is preloading and using the newly
built libstdc++ instead of the system library.

Interestingly, building GCC 4.5.x and lower works fine and is not
showing any of these problems.

However, preloading the 4.5.3 libstdc++ leads to the same problem, as
can be seen in http://trac.macports.org/ticket/27237#comment:16 .

Both GCC versions are configured with --enable-fully-dynamic-strings.
The Apple libc should be using the same feature.

I was searching for what could change linking/preload libraries in the
build system and figured out ltmain.sh does something like this.
Also, there is a testsuite file which messes with that, but ssd on
Freenode/#gcc pointed out that this is only used when running "make check".

Diffing the ltmain.sh of GCC 4.5.3 and 4.6.2 is not helpful either:

---
/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc45/gcc45/work/gcc-4.5.3/ltmain.sh  
 2009-12-05 18:18:53.000000000 +0100
+++ ../../../gcc-4.6.2/ltmain.sh    2011-01-13 19:51:10.000000000 +0100
@@ -5928,7 +5928,7 @@
              test "$hardcode_direct_absolute" = no; then
         add="$dir/$linklib"
           elif test "$hardcode_minus_L" = yes; then
-        add_dir="-L$dir"
+        add_dir="-L$absdir"
         # Try looking first in the location we're being installed to.
         if test -n "$inst_prefix_dir"; then
           case $libdir in

I'm kinda running out of ideas here, what could set DYLD_LIBRARY_PATH to
a bogus value and cause those problems and where?

Please don't suggest GNU ld or gold, as those are ELF-only and not
working on MACH-O systems like Mac OS X. ;)

I hope somebody can help me (and for that matter pretty much all Mac OS
X users.)

Best regards,


Mihai


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4369 bytes --]

Re: Building GCC 4.6.x on Mac OS X

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

* On 30.10.2011 08:25 PM, 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.
Sorry, bad typo correction: __p should *NOT* *ever* be permitted to be a
null pointer for obvious reasons.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4369 bytes --]

Re: Building GCC 4.6.x on Mac OS X

[Jonathan Wakely]

On 30 October 2011 19:25, Mihai Moldovan wrote:
> Hi all,
>
> I've been trying to build GCC 4.6.x on Mac OS X to no avail (with 0 < x
> < 3).

Other people seem to have no problem doing so according to results at
http://gcc.gnu.org/ml/gcc-testresults/2011-10/

Re: Building GCC 4.6.x on Mac OS X

[Jonathan Wakely]

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?

Re: Building GCC 4.6.x on Mac OS X

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

* 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?

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.

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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4369 bytes --]

Re: Building GCC 4.6.x on Mac OS X

[Jonathan Wakely]

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?

Re: Building GCC 4.6.x on Mac OS X

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 3922 bytes --]

* On 30.10.2011 11:18 PM, Jonathan Wakely wrote:
> 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.

By preloading I actually mean forcing the linker to use the new libstdc++.

> 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?

I suspect that too, but the build system should really not force the
libstdc++ on ld, or things like that may happen.
If I interpret www.ionic.de/libstdc++3.diff correctly (diff between GCC
4.5.3 and GCC 4.6.2 libstdc++ with some fuzzyness), the ABI version
changed from 6 to 7. Commonly this happens on breaking ABI changes.
However, even though GCC 4.5.3 libstdc++ had ABI version 6, it can't be
used by ld either, so there is definitely some incompatibility.

Configure line:
../gcc-4.6.1/configure --prefix=/opt/local --build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,lto,fortran
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-libiconv-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-ppl=/opt/local --enable-stage1-checking --disable-multilib
--enable-fully-dynamic-string

I'll try to rebuild with --disable-fully-dynamic-string, but per
http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ I assume this
feature is used in the libc and thus cause even more problems then it
solves.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4369 bytes --]

Re: Building GCC 4.6.x on Mac OS X

[Jonathan Wakely]

On 30 October 2011 22:38, Mihai Moldovan wrote:
>> 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?
>
> I suspect that too, but the build system should really not force the
> libstdc++ on ld, or things like that may happen.
> If I interpret www.ionic.de/libstdc++3.diff correctly (diff between GCC
> 4.5.3 and GCC 4.6.2 libstdc++ with some fuzzyness), the ABI version
> changed from 6 to 7. Commonly this happens on breaking ABI changes.

No, the library ABI version has not changed.  The libstdc++ from GCC
4.6 is backward compatible with the one from libstdc++ 4.5

> However, even though GCC 4.5.3 libstdc++ had ABI version 6, it can't be
> used by ld either, so there is definitely some incompatibility.

Then you're building it differently, with some option that causes an
incompatibility.

> Configure line:
> ../gcc-4.6.1/configure --prefix=/opt/local --build=x86_64-apple-darwin10
> --enable-languages=c,c++,objc,obj-c++,lto,fortran
> --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
> --infodir=/opt/local/share/info --mandir=/opt/local/share/man
> --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
> --with-libiconv-prefix=/opt/local --with-system-zlib --disable-nls
> --program-suffix=-mp-4.6
> --with-gxx-include-dir=/opt/local/include/gcc46/c++/
> --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
> --with-ppl=/opt/local --enable-stage1-checking --disable-multilib
> --enable-fully-dynamic-string

And how was the system compiler (and therefore the system libstdc++) configured?

> I'll try to rebuild with --disable-fully-dynamic-string, but per
> http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ I assume this
> feature is used in the libc and thus cause even more problems then it
> solves.

You can try it, but I doubt it will work.  If system libraries on Mac
OS X use fully-dynamic-string (which I believe they still do) then you
need to use that for your build too.

Re: Building GCC 4.6.x on Mac OS X

[Mihai Moldovan]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

* On 31.10.2011 12:26 AM, Jonathan Wakely wrote:
> On 30 October 2011 22:38, Mihai Moldovan wrote:
>>> 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?
>> I suspect that too, but the build system should really not force the
>> libstdc++ on ld, or things like that may happen.
>> If I interpret www.ionic.de/libstdc++3.diff correctly (diff between GCC
>> 4.5.3 and GCC 4.6.2 libstdc++ with some fuzzyness), the ABI version
>> changed from 6 to 7. Commonly this happens on breaking ABI changes.
> No, the library ABI version has not changed.  The libstdc++ from GCC
> 4.6 is backward compatible with the one from libstdc++ 4.5

Oh, hm, I see... then I may have misinterpreted the namespace version
change, sorry.

> And how was the system compiler (and therefore the system libstdc++) configured?

If I knew... they may or may not have even used clang instead of gcc,
which makes matters worse. (At least they used clang for compiling ld.)

>> I'll try to rebuild with --disable-fully-dynamic-string, but per
>> http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ I assume this
>> feature is used in the libc and thus cause even more problems then it
>> solves.
> You can try it, but I doubt it will work.  If system libraries on Mac
> OS X use fully-dynamic-string (which I believe they still do) then you
> need to use that for your build too.

Wow, something weird just happened. With --disable-fully-dynamic-string,
GCC 4.6.2 build and installed fine... so maybe
_GLIBXX_FULLY_DYNAMIC_STRING is not used in the system libstdc++ after
all. Whilst it's at least compiling now, I'm kind of totally confused.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4369 bytes --]