gcc48 is broken by configure-timespec.patch

[howarth@…]

Please see ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835. It appears that the unnecessary patch libstdc++-configure-timespec.patch is breaking std::promise on darwin.

The alternative fix of ​http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=192335 was checked in to achieve the goal of using nanosleep in c++11.

Note that the fix I checked in for gcc 4.8.0 defaults darwin to --enable-libstdcxx-time so neither that option nor your hack needs to be applied. The g++-fsf-4.8 compiler on fink doesn't fail the test case reported in PR56835 but has nanosleep declared in the object file...

% cd /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.3.0/libstdc++-v3/src/c++11[[BR]]
% nm thread.o | grep nanosleep[[BR]]
                 U _nanosleep[[BR]]

[howarth@…]

Also see ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 which contains a discussion of why your approach was rejected by the FSF gcc maintainers.
They explicitly rejected idea of claiming POSIX timers on darwin when we only have partial support for _POSIX_TIMERS.

[howarth@…]

Also while trying to run the test case under the g++-mp-4.7 compiler exposes the fact that the libgcc_ext stubs are still being pruned rendering the gcc47 compiler useless for this test...

% g++-mp-4.7 -std=c++11 test.cc
Undefined symbols for architecture x86_64:

"_emutls_v._ZSt11once_call", referenced from:

[howarth@…]

backport of fix for gcc47 package

[howarth@…]

I have verified using my fink gcc47 packaging that the attached backport of r192335 to gcc 4.7.4svn also allows
that release to have functional nanosleep support in c++11. I can not test this on MacPorts gcc47 because of
breakage due to the ill-conceived pruning of the libgcc_ext linkages. This obviously has been fixed for the gcc48 package
in MacPorts and those changes need to be backported (especially since you just made gcc47 the default FSF gcc).

Note that patch is already in gcc 4.8.0 so nothing needs to be patched nor does --enable-libstdcxx-time need to be
passed to configure for the nanosleep support to be built in the c++11 threading code of libstdc++.

[cooljeanius (Eric Gallager)]

Cc Me!

[howarth@…]

test case which exposes unnecessary and broken attempt to force nanosleep use in gcc48

[howarth@…]

Looking at the gcc47 and gcc48 Portfile's, it appears to be pure luck that the test case links in the case of gcc48.
Both packages seem to still build their libstdc++'s with the horribly misguided force-static-gcc.patch applied. Using that
patch is gutting the functionality of both packages. A huge amount of effort went in upstream to properly support emutls for
libgomp via the libgcc_ext stubs. Your packages are extremely broken and cause a lot of noise upstream with bogus bug reports
due to a misbuilt gcc compiler.

[howarth@…]

Comparing the gcc47 and gcc48 Portfile's, I see...

@@ -148,6 +134,8 @@

post-destroot {

eval file delete [glob ${destroot}${prefix}/lib/*{a,py}]

+ eval file delete [glob ${destroot}${prefix}/lib/libgcc*]
+ file delete -force ${destroot}${prefix}/lib/gcc

file delete -force ${destroot}${prefix}/share/gcc-${major}
file delete -force ${destroot}${prefix}/include/${name}

I assume somehow this manages to break the configure tests for emutls such that this support is never built.
End users should be made aware that the gcc4x compilers in MacPorts are crippled and are unlikely to pass large sections
of the gcc testsuite. Have you even tried running that? I routinely post the testresults for the fink gcc4x packages
and, outside of the objective c failures on newer darwin, the test results for a properly built FSF gcc are quite good.

​http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02347.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02348.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02414.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02415.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00028.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00729.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01064.html
​http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01065.html

[howarth@…]

To clarify, my understanding is that in order to force a single common libstdc++ package on all of the stable gcc4x releases
the libgcc_ext linkage was gutted from the linkage. This is an extremely high price to pay for dubious packaging benefits. Without
posted gcc-testresults for these MacPorts packages, the amount of breakage this causes, in even just the libstdc++ testsuite results, is
unknown. The assumption that a newer libstdc++ can be used with an older FSF gcc compiler and not introduce regressions is unproven.

[howarth@…]

Note that by omitting libgcc_ext, the following symbols are undefined...

0000000000001300 T _absvti2
0000000000004f00 T _addtf3
0000000000001390 T _addvti3
0000000000001170 T _ashlti3
00000000000011d0 T _ashrti3
00000000000039f0 T _bswapdi2
00000000000039e0 T _bswapsi2
0000000000003a00 T _clrsbdi2
0000000000003a30 T _clrsbti2
0000000000001770 T _clzti2
0000000000001240 T _cmpti2
00000000000017a0 T _ctzti2
0000000000003380 T _divtc3
0000000000006020 T _divtf3
0000000000004570 T _divti3
0000000000010a60 T _emutls_get_address
0000000000010c20 T _emutls_register_common
0000000000006b90 T _eqtf2
000000000000a6d0 T _extenddftf2
000000000000a4a0 T _extendsftf2
000000000000a910 T _extendxftf2
0000000000001740 T _ffsti2
0000000000003e40 T _fixdfti
0000000000003e00 T _fixsfti
0000000000009460 T _fixtfdi
0000000000009070 T _fixtfsi
0000000000009920 T _fixtfti
0000000000003f70 T _fixunsdfti
0000000000003ec0 T _fixunssfti
00000000000095f0 T _fixunstfdi
0000000000009170 T _fixunstfsi
0000000000009b40 T _fixunstfti
0000000000004020 T _fixunsxfti
0000000000003e80 T _fixxfti
0000000000009720 T _floatditf
0000000000009260 T _floatsitf
0000000000004210 T _floattidf
0000000000004140 T _floattisf
0000000000009d10 T _floattitf
00000000000042e0 T _floattixf
0000000000009830 T _floatunditf
0000000000009370 T _floatunsitf
0000000000004420 T _floatuntidf
0000000000004320 T _floatuntisf
000000000000a100 T _floatuntitf
0000000000004520 T _floatuntixf
0000000000006ce0 T _getf2
0000000000006ef0 T _gttf2
0000000000006f00 T _letf2
0000000000001100 T _lshrti3
00000000000070f0 T _lttf2
0000000000004700 T _modti3
0000000000002400 T _multc3
0000000000007100 T _multf3
00000000000010c0 T _multi3
0000000000001500 T _mulvti3
0000000000007b40 T _negtf2
00000000000010e0 T _negti2
00000000000016e0 T _negvti2
0000000000006cd0 T _netf2
0000000000001880 T _parityti2
00000000000017f0 T _popcountti2
00000000000019d0 T _powitf2
0000000000007eb0 T _subtf3
0000000000001450 T _subvti3
000000000000af40 T _trunctfdf2
000000000000ab20 T _trunctfsf2
000000000000b3a0 T _trunctfxf2
0000000000001270 T _ucmpti2
0000000000004b80 T _udivmodti4
00000000000048d0 T _udivti3
0000000000004a10 T _umodti3
0000000000008fe0 T _unordtf2
0000000000010520 T darwin10_Unwind_FindEnclosingFunction

for libgcc_ext.10.5.dylib whilte the compiler expects it can safely emit these (many of which are newer math functions)

[howarth@…]

Also note...

% nm libgfortran.3.dylib | grep addtf3

U _addtf3

% nm libgfortran.3.dylib | grep divtf3

U _divtf3

% nm libgfortran.3.dylib | grep divti3

U _divti3

% nm libgfortran.3.dylib | grep divtf3

U _divtf3

% nm libgfortran.3.dylib | grep divti3

U _divti3

% nm libgfortran.3.dylib | grep eqtf2

U _eqtf2

% nm libgfortran.3.dylib | grep floatditf

U _floatditf

% nm libgfortran.3.dylib | grep floatsitf

U _floatsitf

% nm libgfortran.3.dylib | grep floatunditf

U _floatunditf

% nm libgfortran.3.dylib | grep getf2

U _getf2

% nm libgfortran.3.dylib | grep gttf2

U _gttf2

% nm libgfortran.3.dylib | grep letf2

U _letf2

% nm libgfortran.3.dylib | grep lttf2

U _lttf2

% nm libgfortran.3.dylib | grep modti3

U _modti3

% nm libgfortran.3.dylib | grep multf3

U _multf3

% nm libgfortran.3.dylib | grep netf2

U _netf2

% nm libgfortran.3.dylib | grep subtf3

U _subtf3

% nm libgfortran.3.dylib | grep trunctfdf2

U _trunctfdf2

% nm libgfortran.3.dylib | grep udivti3

U _udivti3

% nm libgfortran.3.dylib | grep umodti3

U _umodti3

% nm libgfortran.3.dylib | grep unordtf2

U _unordtf2

from libgcc_ext are used in libgfortran with a normal build. Building libgfortran with using those calls would be a massive
untested fork in the compiler.

[howarth@…]

Why is gcc48 still providing the libstdcxx-devel subport when gcc 4.8.0 is the most current stable release?
Gcc 4.8.0 was released on March 22 and you are using the gcc-4_8-branch snapshot of gcc 4.8.1 instead.
There should be a gcc49 created now instead to own the libstdcxx-devel subport.

[jeremyhu (Jeremy Huddleston Sequoia)]

Jack, calm down. Your rage won't get things done around here. #38500 covers bumping gcc48 to stable.

libstdc++.dylib is intended to be self contained and usable by versions of gcc equal or older than the one used to build it.

from libgcc_ext are used in libgfortran with a normal build.

Why are you bringing up libgfortran here? I thought you were complaining about libstdc++.dylib. How is this related? If libgfortran is using those symbols, that seems fine to me. It should be linking against libgcc_ext.

Building libgfortran with using those calls would be a massive untested fork in the compiler.

If those are used in a "normal build" ... why would using them be "a massive untested fork"?

The assumption that a newer libstdc++ can be used with an older FSF gcc compiler and not introduce regressions is unproven.

I don't know where you come up with that. This "assumption" was how Apple operated prior to moving to clang and libc++; it's "assumed" by pretty much every Linux distribution; and if it were made incompatible, the library version would need to be bumped in order to call out the changes (which hasn't happened).

[jeremyhu (Jeremy Huddleston Sequoia)]

r105106

[jeremyhu (Jeremy Huddleston Sequoia)]

Regarding your concerns about other issues (eg: libgfortran linkage), please file a new ticket explaining why you feel there is a problem there.

If you are interested in helping out in maintaining the toolchain in MacPorts, there's plenty of room to help out with patches, running the test suite, etc.

[howarth@…]

I'll try to find sometime to do testsuite runs on the gcc47 and gcc48 to see how they hold up and will open a separate ticket about the fact that gcc48 should now own libstdc++ and
a gcc49 should be created to provide libstdc++-devel. I am unclear on how the migration from gcc47 providing libstdc++ to gcc48 providing libstdc++ is supposed to be done.
Has this transfer of ownership for libstdc++ been done for gcc4x packages before or has gcc47 always owned libstdc++ since the subport was introduced?

[howarth@…]

Also note that when gcc 4.7.4 is released shortly, it will still need gcc47_libstdc++_c++11_nanosleep.diff​ to solve PR56835.
I haven't had time to backport r192335 into gcc-4_7-branch in time for the gcc 4.7.4 release.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to howarth@…:

will open a separate ticket about the fact that gcc48 should now own libstdc++ and a gcc49 should be created to provide libstdc++-devel.

As mentioned above, #38500 covers that.

I am unclear on how the migration from gcc47 providing libstdc++ to gcc48 providing libstdc++ is supposed to be done.

Easy, commit gcc49 providing -devel, gcc48 providing stable, and remove it from gcc47 at the same time.

Has this transfer of ownership for libstdc++ been done for gcc4x packages before or has gcc47 always owned libstdc++ since the subport was introduced?

No, gcc47 was the first to provide libstdcxx, but it was intended to move up to the current stable version.

[howarth@…]

Note that current libstdc++ subport of gcc47 is lacking the emutls symbols which means that the test.cc testcase can't be compiled with gcc47.
If you promote the libstdc++-devel in gcc48 to become libstdc++ (and remove the libstdc++ subport from gcc47), this issue will
be solved. The force-static-gcc.patch, which insures that these additional symbols are present, is used for libstdc++-devel of gcc48 but not in the libstdc++
of gcc47.

[howarth@…]

It appears that the breakage in the test.cc testcase is coming from somewhere else (perhaps your customized tool chain)?

% g++-mp-4.8 -std=c++11 test.cc
% ./a.out
doing the test
Segmentation fault

still occurs using the packaging from ticket 38758. I also see this with the force-static-gcc.patch disabled.
I am in the process of testing a build with the *_FOR_TARGET configure options set to point at /usr/bin rather than ${prefix}/bin to see if using the Xcode 4.6.1 toolchain solves this.

[howarth@…]

Using the Xcode 4.6.1 toolchain doesn't eliminate the problem.
Note the testcase failure backtraces as...
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010008dc40 in once_proxy ()
(gdb) bt
#0 0x000000010008dc40 in once_proxy ()
#1 0x00007fff8c8d7ff0 in pthread_once ()
#2 0x0000000100000fd2 in gthread_once (once=0x100303b80, func=0x10008dc30 <once_proxy>) at gthr-default.h:699
#3 0x00000001000020c9 in _ZSt9call_onceIMNSt13future_base11_State_baseEFvRSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEERbEIKPS1_St17reference_wrapperIS8_ESF_IbEEEvRSt9once_flagOT_DpOT0_ (once=@0x100303b80, f=@0x7fff5fbfede0) at mutex:783
#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_managerINSt13future_base11_State_base7_SetterIbObEEE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation>}, _M_invoker = 0x10000372d <_ZNSt17_Function_handlerIFSt10unique_ptrINSt13future_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
#6 0x000000010000119f in main () at test.cc:8

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

[howarth@…]

This packaging exhibits some bizarre behavior. In an attempt to rebuild the package without the force-static-gcc.patch, I executed 'sudo port uninstall gcc48',
'sudo port uninstall libstdcxx' and 'sudo port clean gcc48' (as 'sudo port libstdcxx' appears to not be valid). Afterwards when I did 'sudo port -d install gcc48'
gcc48 was rebuilt but the archive for libstdcxx-4.8.0_0.darwin_12.x86_64.tbz2 in /opt/local/var/macports/software shows a much older timestamp. This makes
me suspect that the additional rebuilds of gcc48 are only rebuilding the gcc48 package and not really the libstdc++ subport. Surely this must be a corner case bug
in how port rebuilds subports no? If so this makes testing rebuilds of this package horribly complex.

[howarth@…]

Okay, the combination of building with the normal bootstrap, removing the static libgcc linkage and using the Xcode 4.6 cctools solves the test case crash.
Now I need to find the exact change that eliminates the crash.

[howarth@…]

Ouch. By linking libgcc_eh.a into libstdc++, you guys have managed to cause executables generated by g++-mp-4.8 to use two different unwinders (which the darwin linker developer
long ago said is forbidden). My understanding is that static linkages of libgcc_eh will force the FSF gcc unwinder symbols to be used instead of those from libSystem (which on darwin11/12
will be from the compatibility unwinder). So code inside of the libstdc++ dylib will execute on the FSF gcc unwinder in libgcc_eh.a while other code modules compiled by g++-mp-4.8 will be
executing on the libSysyem unwinder (which is the desired one).

[jeremyhu (Jeremy Huddleston Sequoia)]

Which just means that gcc's '-static-libgcc' support is broken on darwin, and MacPorts' libstdc++.dylib is broken because of that...

So then we nee a patch which removes unwind from libgcc_eh and thus allows code built with -static-libgcc to use libunwind from libSystem.

[jeremyhu (Jeremy Huddleston Sequoia)]

Actually ... it looks like it is using libSystem's provided libunwind already

~ $ nm -m /opt/local/lib/libstdc++.6.dylib | grep Unwind
                 (undefined) external __Unwind_DeleteException (from libSystem)
                 (undefined) external __Unwind_GetDataRelBase (from libSystem)
                 (undefined) external __Unwind_GetIPInfo (from libSystem)
                 (undefined) external __Unwind_GetLanguageSpecificData (from libSystem)
                 (undefined) external __Unwind_GetRegionStart (from libSystem)
                 (undefined) external __Unwind_GetTextRelBase (from libSystem)
                 (undefined) external __Unwind_RaiseException (from libSystem)
                 (undefined) external __Unwind_Resume (from libSystem)
                 (undefined) external __Unwind_Resume_or_Rethrow (from libSystem)
                 (undefined) external __Unwind_SetGR (from libSystem)
                 (undefined) external __Unwind_SetIP (from libSystem)
00000000000028dc (__TEXT,__text) non-external __ZL17parse_lsda_headerP15_Unwind_ContextPKhP16lsda_header_info
00000000000028a8 (__TEXT,__text) non-external __ZL18read_encoded_valueP15_Unwind_ContexthPKhPm
0000000000002860 (__TEXT,__text) non-external __ZL21base_of_encoded_valuehP15_Unwind_Context
000000000000312b (__TEXT,__text) non-external __ZL22free_any_cxa_exceptionP17_Unwind_Exception
000000000000321d (__TEXT,__text) non-external __ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception
0000000000002e97 (__TEXT,__text) non-external __ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception

[howarth@…]

See

​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

Also unfortunately, its not that simple as just removing -lgcc_eh from the linkage of libstdc++ as that will result in undefined symbols for _emutls_v._ZSt11once_call and
_emutls_v._ZSt15once_callable when the test case is compiled with that build of the compiler. This is because libgcc_eh also provides emutls symbols.
So you're pretty much stuck with...

a) living with the broken exception handling in FSF libstdc++
b) reverting back to a separate normally linked libstdc++ in each gcc4x package
c) attampting to create a libgcc_s splitoff for the newest gcc4x which will be used by all the gcc4x packages

This is an awful lot of pain for having a single libstdc++ package.

ps We don't normally run into this breakage with -static-gcc because when passed to g++, both the static libgcc and libstdc++ are linked in.
So while the wrong unwinder is used, the code doesn't break because only a single unwinder is used.
pps Relying on static linkage on darwin has always been fringe behavior because Apple has always discouraged and minimized its use.

[howarth@…]

patch required for new gcc48 Portfile.

[howarth@…]

IMHO, the attachd Portfile.diff and associated patch is your best bet. It simply folds libgcc*dylib from the gcc48 package into the libstdcxx subport.
The other gcc4x packages will need to revision bumped with the line...

eval file delete [glob ${destroot}${prefix}/lib/libgcc*]

added to their post-destroot.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to howarth@…:

See

​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
​http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

Also unfortunately, its not that simple as just removing -lgcc_eh from the linkage of libstdc++

I never suggested that. I suggested removing the unwinding code from libgcc_eh since that is what you claimed introduced the conflict, but as shown above, it looks like libstdc++.dylib is using the libSystem libunwind and not anything from libgcc_eh for unwind.

as that will result in undefined symbols for _emutls_v._ZSt11once_call and
_emutls_v._ZSt15once_callable when the test case is compiled with that build of the compiler. This is because libgcc_eh also provides emutls symbols.
So you're pretty much stuck with...

a) living with the broken exception handling in FSF libstdc++

Not ideal.

b) reverting back to a separate normally linked libstdc++ in each gcc4x package

No, as mentioned before, that is not a possibility.

c) attampting to create a libgcc_s splitoff for the newest gcc4x which will be used by all the gcc4x packages

I'd prefer to not have separate libgcc runtime as well. I was really hoping to avoid that, but it's not out of the question.

ps We don't normally run into this breakage with -static-gcc because when passed to g++, both the static libgcc and libstdc++ are linked in.

You seem to miss the point entirely... each binary would then have its *own* C++ runtime in this situation, and all of them would conflict, so libQT would have a separate C++ runtime than myQTApp, and passing objects between them would be a nightmare.

So while the wrong unwinder is used

Are you sure about that? As I showed above, libstdc++.dylib is resolving its Unwind* symbols to libSystem...

, the code doesn't break because only a single unwinder is used.

Uh, no... multiple would (one per image)

pps Relying on static linkage on darwin has always been fringe behavior because Apple has always discouraged and minimized its use.

Yes, which is why I don't provide a libstdc++.a in the package, but it's perfectly acceptable to use static archives within a single project to help collect and organize submodules.

[howarth@…]

Removing the unwinder symbols will be non-trivial and we will get any help from upstream in safely implementting that.
Your best shot is to move the libgcc* dylibs into libstdcxx. I am working on adding the missing symlinks the Portfile to make that work.

[howarth@…]

Replying to jeremyhu@…:

So while the wrong unwinder is used

Are you sure about that? As I showed above, libstdc++.dylib is resolving its Unwind* symbols to libSystem...

, the code doesn't break because only a single unwinder is used.

Try 'g++-mp-4.8 -std=c++11 test.cc' with the current gcc48 packaging and you will find the test case still segfaults.
If this problem occurs only for darwin10 and later, we probably are running into the complexities with using static libs under the faster
c++ weak-symbol coalescing introduced in darwin10. We have a similar problem in static linkage into libitm in FSF gcc
(see ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693#c40 and ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693#c41 for
details. Basically, when c++ weak-symbol coalescing was made faster, the cost was that non-weak symbols in libstdc++ dylib would now
be overridden by those from a static lib linked in. It took us a long time to understand the subtly of that problem but the darwin
linker developer helped us tease that issue out.

[howarth@…]

Portfile diff implementing move of libgcc*dylib into libstdcxx

[howarth@…]

patch to skip installation of libffi

[howarth@…]

I have uploaded a revised Portfile.diff and the new patch to skip installation of libffi. This packaging moves the libgcc*dylib
files into the libstdcxx subport. Note that I had to build both the c and c++ compilers with a normal bootstrap in order to
get all of the emutls symbols in the libstdc++ installed by the libstdcxx subport. While this is slower, libgcc really should be
built from a full bootstrap to insure that the code generation from the compiler used was stable. Since you are using binary
distributions this added compile time should be transparent to the end users of MacPorts. This new packaging allows the
test case compiled with 'g++-mp-4.8 -std=c++11 test.cc' to execute without failures...

% g++-mp-4.8 -std=c++11 test.cc
% ./a.out
doing the test
success, result is 1

ps Each gcc4x package will now need that same synlinks added to point at the matching libgcc*dylib files in ${prefix}/lib
The presence of libgcc_s.1.dylib there shouldn't be an issue as Apple's compliers never directly linked -lgcc_s but used
the versioned stubs -lgcc_s.10.4 or -lgcc_s.10.5 (which were dropped in darwin10 when those symbols were subsumed into libSystem).

[howarth@…]

add requested epoch

[howarth@…]

Not fixed yet as test case still crashes due to static linkage of libgcc in libstdc++ dylib.

[jeremyhu (Jeremy Huddleston Sequoia)]

*THIS* issue is fixed. That issue you are discussing should be tracked in a separate bug as it is a different issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

Regarding your concern about bootstrapping, see #36116 r103047

[mf2k (Frank Schima)]

And please start using proper WikiFormatting. Your comments border on unreadable.

• Enclose code snippets in triple brackets: {{{ and }}}.
• Ticket references should be like ticket:12345.
• Revision changes should be like r12345.
• [[BR]] should almost never be used.

[howarth@…]

Alternatively, why can't Trac implement a decent user interface that automates those actions instead of demanding users 'program' their messages as if they were writing in Tex. This only creates an additional barrier to users and potential packagers working with MacPorts. Also, if the way I code messages is so bad, why does the Preview always look reasonable. Pretty dodgy interface.

[mf2k (Frank Schima)]

WYSIWYG would be nice, but Trac is what we use and you have to play by its rules. Those 4 rules are the most important to remember. That and lists.

[howarth@…]

How about even providing the ability to edit your own messages after posting? It wouldn't be so painful to start exploring advanced wikiformatting if that option were available.

[jmroot (Joshua Root)]

Replying to howarth@…:

How about even providing the ability to edit your own messages after posting?

Click the "Edit" button.

[howarth@…]

Replying to jmr@…:

Replying to howarth@…:

How about even providing the ability to edit your own messages after posting?

Click the "Edit" button.

What changed? I never saw the Edit button next to my messages on trac.macports.org before your last posting.