[MacPorts] #38732: gcc48 is broken by configure-timespec.patch

[MacPorts]

#38732: gcc48 is broken by configure-timespec.patch
------------------------+--------------------
  Reporter:  howarth@…  |      Owner:  mww@…
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.1.3
Resolution:  fixed      |   Keywords:
      Port:  gcc48      |
------------------------+--------------------

Comment (by howarth@…):

 Using the Xcode 4.6.1 toolchain doesn't eliminate the problem.[[BR]]
 Note the testcase failure backtraces as...[[BR]]
 Program received signal EXC_BAD_ACCESS, Could not access memory.[[BR]]
 Reason: 13 at address: 0x0000000000000000[[BR]]
 0x000000010008dc40 in __once_proxy ()[[BR]]
 (gdb) bt[[BR]]
 #0  0x000000010008dc40 in __once_proxy ()[[BR]]
 #1  0x00007fff8c8d7ff0 in pthread_once ()[[BR]]
 #2  0x0000000100000fd2 in __gthread_once (__once=0x100303b80,
 __func=0x10008dc30 <__once_proxy>) at gthr-default.h:699 [[BR]]
 #3  0x00000001000020c9 in
 _ZSt9call_onceIMNSt13__future_base11_State_baseEFvRSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEERbEIKPS1_St17reference_wrapperIS8_ESF_IbEEEvRSt9once_flagOT_DpOT0_
 (__once=@0x100303b80, __f=@0x7fff5fbfede0) at mutex:783 [[BR]]
 #4  0x0000000100001886 in std::__future_base::_State_base::_M_set_result
 (this=0x100303af8,
 __res={<_Maybe_unary_or_binary_function<std::unique_ptr<std::__future_base::_Result_base,
 std::__future_base::_Result_base::_Deleter> >> = {<No data fields>},
 <std::_Function_base> = {static _M_max_size = <optimized out>, static
 _M_max_align = <optimized out>, _M_functor = {_M_unused = {_M_object =
 0x1003000e0, _M_const_object = 0x1003000e0, _M_function_pointer =
 0x1003000e0, _M_member_pointer = {__pfn = 0x1003000e0, __delta =
 140734799801968}}, _M_pod_data = "?\0000\000\001\000\000\000p?_?\000"},
 _M_manager = 0x100003780
 <_ZNSt14_Function_base13_Base_managerINSt13__future_base11_State_base7_SetterIbObEEE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation>},
 _M_invoker = 0x10000372d
 <_ZNSt17_Function_handlerIFSt10unique_ptrINSt13__future_base12_Result_baseENS2_8_DeleterEEvENS1_11_State_base7_SetterIbObEEE9_M_invokeERKSt9_Any_data>},
 __ignore_failure=false) at future:358[[BR]]
 #5  0x00000001000025ef in std::promise<bool>::set_value
 (this=0x7fff5fbfee80, __r=@0x7fff5fbfee9e) at future:994 [[BR]]
 #6  0x000000010000119f in main () at test.cc:8 [[BR]]
 [[BR]]
 The next step in debugging this would seem to be refactor the libstdc++
 subport to use the libstdc++ from the normal bootstrap (in case this
 failure is a side-effect of the highly unusual way you build libstdc++).

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