[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 Peter_Dyballa@…):

 Replying to [comment:15 jeremyhu@…]:
 > Replying to [comment:14 Peter_Dyballa@…]:

 >
 > 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 had them, but right now they are not installed. When they were they did
 not change the situation.

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

 It's not. GCC 47 does not use libbacktrace. Here are the top-level
 directories of gcc-4.7.3:

 {{{
 drwxr-xr-x  14 root admin     476 11. Apr 09:59 INSTALL
 drwxr-xr-x  87 root admin    2958 11. Apr 09:57 boehm-gc
 drwxr-xr-x  77 root admin    2618 11. Apr 09:57 config
 drwxr-xr-x  41 root admin    1394 11. Apr 09:57 contrib
 drwxr-xr-x  29 root admin     986 11. Apr 09:59 fixincludes
 drwxr-xr-x 649 root admin   22066 28. Aug 22:20 gcc
 drwxr-xr-x   6 root admin     204 11. Apr 09:58 gnattools
 drwxr-xr-x  33 root admin    1122 11. Apr 09:57 include
 drwxr-xr-x  44 root admin    1496 11. Apr 09:57 intl
 drwxr-xr-x   6 root admin     204 11. Apr 09:59 libada
 drwxr-xr-x  30 root admin    1020 11. Apr 09:59 libcpp
 drwxr-xr-x  41 root admin    1394 11. Apr 09:58 libdecnumber
 drwxr-xr-x  23 root admin     782 11. Apr 09:59 libffi
 drwxr-xr-x  67 root admin    2278 11. Apr 09:58 libgcc
 drwxr-xr-x  38 root admin    1292 11. Apr 09:59 libgfortran
 drwxr-xr-x  20 root admin     680 11. Apr 09:58 libgo
 drwxr-xr-x  41 root admin    1394 11. Apr 10:13 libgomp
 drwxr-xr-x 144 root admin    4896 11. Apr 09:57 libiberty
 drwxr-xr-x  43 root admin    1462 11. Apr 11:12 libitm
 drwxr-xr-x  78 root admin    2652 28. Aug 22:20 libjava
 drwxr-xr-x  19 root admin     646 11. Apr 09:57 libmudflap
 drwxr-xr-x  38 root admin    1292 11. Apr 09:58 libobjc
 drwxr-xr-x  21 root admin     714 28. Aug 22:20 libquadmath
 drwxr-xr-x  28 root admin     952 11. Apr 09:59 libssp
 drwxr-xr-x  38 root admin    1292 11. Apr 09:57 libstdc++-v3
 drwxr-xr-x  11 root admin     374 11. Apr 09:57 lto-plugin
 drwxr-xr-x  10 root admin     340 11. Apr 09:58 maintainer-scripts
 drwxr-xr-x  50 root admin    1700 11. Apr 09:57 zlib
 }}}

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

 Static linking was clear, but what does that "_eh" in the name signify?
 And why does it have the library function?

 libbacktrace/configure also has this error on line #11653:

 {{{
   ac_save_CFFLAGS="$CFLAGS"
 }}}

 GNU Emacs cannot find another occurrence of "CFFLAGS". I think the macro
 "ac_fn_c_try_compile" on line #11670 is the key:

 {{{
 if ac_fn_c_try_compile "$LINENO"; then :
 }}}

 Presumingly I'm ought to substitute the macro with ac_fn_c_try_link…
 Right?

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