[MacPorts] #36226: libstdcxx @4.7.1: cc1 in stage1 can't be built on PPC Tiger (Mac OS X 10.4.11) due to undefined symbols

[MacPorts]

#36226: libstdcxx @4.7.1: cc1 in stage1 can't be built on PPC Tiger (Mac OS X
10.4.11) due to undefined symbols
------------------------------+------------------------
  Reporter:  Peter_Dyballa@…  |      Owner:  jeremyhu@…
      Type:  defect           |     Status:  reopened
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.1.2
Resolution:                   |   Keywords:
      Port:  libstdcxx        |
------------------------------+------------------------

Comment (by jeremyhu@…):

 Replying to [comment:14 Peter_Dyballa@…]:
 > I think the cause is in this report:
 >
 > {{{
 > config.log
 > ==========
 > configure:11652: checking for _Unwind_GetIPInfo
 > configure:11667: /opt/local/bin/gcc-apple-4.2 -arch ppc -c -g -H -Wl,-t
 -Werror-implicit-function-declaration  conftest.c >&5
 > . /opt/local/lib/apple-gcc42/gcc/powerpc-apple-
 darwin8/4.2.1/include/unwind.h
 > powerpc-apple-darwin8-gcc-apple-4.2.1: -t: linker input file unused
 because linking not done
 > configure:11667: $? = 0
 > configure:11674: result: yes
 > }}}

 Yep.

 > I patched CFLAGS a bit to see more of the compilation test. I think
 removing the "-c" option would be the proper test.

 Yes, I agree.

 They are looking for the symbol, and it's possible that the definition
 exists because of libunwind-headers (which would let it compile but not
 link).  Do you have libunwind-headers installed?  Does it work if you
 remove them?

 I wonder if this is a regression introduced to configure in gcc48.  If
 backtrace.c exists in gcc47, I'd focus my efforts on comparing the two
 configure scripts.

 > I actually don't know what's libgcc_eh.a good for – but it somehow
 works…

 It's for static linking.  It is not the right solution.

-- 
Ticket URL: <https://trac.macports.org/ticket/36226#comment:15>
MacPorts <http://www.macports.org/>
Ports system for OS X