libstdcxx can't resolve ___emutls_get_address

[angelo.graziosi@…]

On Lion 10.7.4 and Xcode 4.4.1 I did

$ sudo port selfupdate
[...]

$ sudo port outdated
[...]

$ sudo port upgrade outdated
[...]

and as consequence of GCC47 upgrade ROOT (with all my variant) was rebuilt. But it failed!

Atthaced are the main log and the output of above commands.

[angelo.graziosi@…]

main log

[cjones051073 (Chris Jones)]

For some reason, the update is trying to update ROOT with different variants to that currently installed, and that isn't allowed.

I don't know why its doing that, but try manually uninstalling and cleaning root, then reinstall using whatever variants you want

sudo port uninstall root
sudo port clean --all root
sudo port install root +.....

Chris

[angelo.graziosi@…]

Ciao Chris,

really I did that, but it fails...

Now I haven't a good internet connection that allow me for re-trying.. This night, perhaps... then I will sent you also athe new main.log...

BTW, the problem seems be caused by iAIDA. I have geant4 which depends on iAIDA which depends on ROOT which depend on GCC47. When it computes the iAIDA dependencies, it tries diferent variants fo ROOT. Please, re-read the upgrade_outdated.out file I have attached in my post...

Anyway, as I said, even uninstalling, cleaning and reinstalling from scratch ROOT with all variants I had, it fails.

Ciao,

Angelo.

Replying to jonesc@…:

For some reason, the update is trying to update ROOT with different variants to that currently installed, and that isn't allowed.

I don't know why its doing that, but try manually uninstalling and cleaning root, then reinstall using whatever variants you want

sudo port uninstall root
sudo port clean --all root
sudo port install root +.....

Chris

[cjones051073 (Chris Jones)]

It doesn't look to me like there is anything wrong with the ROOT port here.

The problem is during your upgrade it found a lot of broken ports, and it is trying to fix them. During this it tries to reinstall iAIDA but this falls over with the variants mis-match

--->  Found 195 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
     iAIDA @1.0.22
--->  Computing dependencies for iAIDA
--->  Dependencies to be installed: root
Error: Requested variants "+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml" do not match original selection "+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml".
Please use the same variants again, perform 'port clean root' or specify the force option (-f).
Error: Failed to install root

It looks like the automate rebuild at this point is not respecting the custom variants you have installed. If so, this is one for the MacPorts devs...

I suggest uninstalling iAIDA and root, then rerun the 'upgrade outdated' to make sure everything else is updated and all the other broken files are fixed.

Once all that is OK, then add back root followed by iAIDA.

Chris

[angelo.graziosi@…]

Replying to jonesc@…:

It doesn't look to me like there is anything wrong with the ROOT port here.

The problem is during your upgrade it found a lot of broken ports, and it is trying to fix them. During this it tries to reinstall iAIDA but this falls over with the variants mis-match

--->  Found 195 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
     iAIDA @1.0.22
--->  Computing dependencies for iAIDA
--->  Dependencies to be installed: root
Error: Requested variants "+graphviz+gsl+minuit2+opengl+roofit+soversion+ssl+tmva+xml" do not match original selection "+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml".
Please use the same variants again, perform 'port clean root' or specify the force option (-f).
Error: Failed to install root

It looks like the automate rebuild at this point is not respecting the custom variants you have installed. If so, this is one for the MacPorts devs...

I suggest uninstalling iAIDA and root, then rerun the 'upgrade outdated' to make sure everything else is updated and all the other broken files are fixed.

Once all that is OK, then add back root followed by iAIDA.

I have done this:

$ sudo port -f uninstall geant4
Password:
--->  Deactivating geant4 @4.9.4.p02_0+aida+athena+gdml+global+motif+raytracerx+shared
--->  Cleaning geant4
--->  Uninstalling geant4 @4.9.4.p02_0+aida+athena+gdml+global+motif+raytracerx+shared
--->  Cleaning geant4


$ sudo port -f uninstall iAIDA
--->  Deactivating iAIDA @1.0.22_0
--->  Cleaning iAIDA
--->  Uninstalling iAIDA @1.0.22_0
--->  Cleaning iAIDA


$ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.1.2 installed,
MacPorts base version 2.1.2 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated

$ sudo port outdated
The following installed ports are outdated:
gcc45                          4.5.4_2 < 4.5.4_3         
gcc46                          4.6.3_5 < 4.6.3_6         
gcc47                          4.7.1_3 < 4.7.1_4         
gcc48                          4.8-20120909_1 < 4.8-20120909_2



$ sudo port upgrade outdated
--->  Computing dependencies for gcc45
--->  Fetching archive for gcc45
--->  Attempting to fetch gcc45-4.5.4_3.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc45
--->  Attempting to fetch gcc45-4.5.4_3.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/gcc45
--->  Installing gcc45 @4.5.4_3
--->  Cleaning gcc45
--->  Computing dependencies for gcc45
--->  Deactivating gcc45 @4.5.4_2
--->  Cleaning gcc45
--->  Activating gcc45 @4.5.4_3
--->  Cleaning gcc45
--->  Computing dependencies for gcc46
--->  Fetching archive for gcc46
--->  Attempting to fetch gcc46-4.6.3_6.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc46
--->  Attempting to fetch gcc46-4.6.3_6.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/gcc46
--->  Installing gcc46 @4.6.3_6
--->  Cleaning gcc46
--->  Computing dependencies for gcc46
--->  Deactivating gcc46 @4.6.3_5
--->  Cleaning gcc46
--->  Activating gcc46 @4.6.3_6
--->  Cleaning gcc46
--->  Computing dependencies for gcc47
--->  Fetching archive for gcc47
--->  Attempting to fetch gcc47-4.7.1_4.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc47
--->  Attempting to fetch gcc47-4.7.1_4.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/gcc47
--->  Installing gcc47 @4.7.1_4
--->  Cleaning gcc47
--->  Computing dependencies for gcc47
--->  Deactivating gcc47 @4.7.1_3
--->  Cleaning gcc47
--->  Activating gcc47 @4.7.1_4
--->  Cleaning gcc47
--->  Computing dependencies for gcc48
--->  Fetching archive for gcc48
--->  Attempting to fetch gcc48-4.8-20120909_2.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc48
--->  Attempting to fetch gcc48-4.8-20120909_2.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/gcc48
--->  Installing gcc48 @4.8-20120909_2
--->  Cleaning gcc48
--->  Computing dependencies for gcc48
--->  Deactivating gcc48 @4.8-20120909_1
--->  Cleaning gcc48
--->  Activating gcc48 @4.8-20120909_2
--->  Cleaning gcc48
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

$ sudo port install root +avahi +fftw3 +fitsio +gcc47 +ldap +mysql +odbc +postgresql92 +pythia +python32 +ruby
Password:
--->  Computing dependencies for root
--->  Fetching archive for root
--->  Attempting to fetch root-5.34.01_1+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml.darwin_11.x86_64.tbz2 from http://packages.macports.org/root
--->  Attempting to fetch root-5.34.01_1+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/root
--->  Attempting to fetch root-5.34.01_1+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/root
--->  Fetching distfiles for root
--->  Attempting to fetch root_v5.34.01.source.tar.gz from http://root.cern.ch/download/
--->  Verifying checksum(s) for root
--->  Extracting root
--->  Applying patches to root
--->  Configuring root
--->  Building root
Error: org.macports.build for port root returned: command execution failed
Please see the log file for port root for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_root/root/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port root failed

I think it is related to recent changes in GCC47,46,45,48. The same failure of the build of PDFTK (see ticket # 36092).

I have tried to sent the main.log (compressed) but the tracker says it is too large (70K). So I will sent in some other way.

Ciao, Angelo.

[cjones051073 (Chris Jones)]

My suspicion is this is indeed due to changes in the gcc ports. There is a discussion on the dev mailing list, which seems like it could be the same thing.

​http://lists.macosforge.org/pipermail/macports-dev/2012-September/020322.html

Chris

[cjones051073 (Chris Jones)]

For reference, the primary error in the log is

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::ctype<char>::_M_widen_init() const", referenced from:
:info:build       Reflex::DictionaryGenerator::Use_selection(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in DictionaryGenerator.o
:info:build       Reflex::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Reflex::DictionaryGenerator const&) in DictionaryGenerator.o

the missing symbol is something that should be provided by the gcc 4.7 libstdc++ I think.

Chris

[angelo.graziosi@…]

See #35770...

Replying to jonesc@…:

For reference, the primary error in the log is

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::ctype<char>::_M_widen_init() const", referenced from:
:info:build       Reflex::DictionaryGenerator::Use_selection(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in DictionaryGenerator.o
:info:build       Reflex::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Reflex::DictionaryGenerator const&) in DictionaryGenerator.o

the missing symbol is something that should be provided by the gcc 4.7 libstdc++ I think.

Chris

[cjones051073 (Chris Jones)]

Indeed. ticket 35770 looks like it is what has caused this....

I've made my comment there. This change looks a tad stupid to me.

Unfortunately, nothing I can do from the root side. For the time being, you just will have to not use the gcc variants...

Chris

[angelo.graziosi@…]

Replying to jonesc@…:

Indeed. ticket 35770 looks like it is what has caused this....

I've made my comment there. This change looks a tad stupid to me.

I AGREE...

Unfortunately, nothing I can do from the root side. For the time being, you just will have to not use the gcc variants...

I can't... :-(

I have all based on gcc variants... and now I am in the situation in which Geant4 (which depend on iAIDA which depend on ROOT), ROOT disappeared from my MacPorts installation.. :-(

Angelo

[angelo.graziosi@…]

Now I have installed ROOT, after the libstdcxx fix to GCC47, but running some ROOT test, I got:

$ ./stressMathCore
Beta distribution                       		................ OK
Gamma distribution                      		................ OK
Chisquare distribution                  		................ OK
Normal distribution                     		................ OK
BreitWigner distribution                		................ OK
F    distribution                       		................ OK
lognormal distribution                  		................ OK
[...]
SMatrix<Double32_t,5,5,MatRepSym> after read		................ OK
******************************************************************************
	Test of a Composite Object (containing Vector's and Matrices)
******************************************************************************
Test Using CINT library

Error in <TUnixSystem::DynamicPathName>: ../test/libTrackMathCoreDict[.so | .dll | .dylib | .sl | .dl | .a] does not exist in .:/opt/local/lib/root::/opt/local/lib/root/cint/cint/stl
Error in <TUnixSystem::DynamicPathName>: test/libTrackMathCoreDict[.so | .dll | .dylib | .sl | .dl | .a] does not exist in .:/opt/local/lib/root::/opt/local/lib/root/cint/cint/stl
Error Loading libTrackMathCoreDictdyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Trace/BPT trap: 5

which still looks related to the cited fix, ticket #35770...

Angelo

Replying to jonesc@…:

Indeed. ticket 35770 looks like it is what has caused this....

I've made my comment there. This change looks a tad stupid to me.

Unfortunately, nothing I can do from the root side. For the time being, you just will have to not use the gcc variants...

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Angelo, please post the output of:

nm -m /opt/local/lib/libstdc++.6.dylib

[angelo.graziosi@…]

the output of "nm -m /opt/local/lib/libstdc++.6.dylib"

[angelo.graziosi@…]

Until now, I have found that problem only with that test (stressMathMore) , but it should not occur in any case...

I have attached the output of the "nm -m /opt/local/lib/libstdc++.6.dylib".

Angelo

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks. I think I see what the issue is. It looks like I'll need to fix the "TODO: Fix this in the build system" workaround sooner rather than later since it looks like there are actually some configs that do end up using newer gcc runtime symbols...

[jeremyhu (Jeremy Huddleston Sequoia)]

I have a fix that looks good ... just waiting on one machine to finish building so I can test it there...

[jeremyhu (Jeremy Huddleston Sequoia)]

r97744

[angelo.graziosi@…]

Replying to jeremyhu@…:

Angelo, please post the output of:

nm -m /opt/local/lib/libstdc++.6.dylib

I didn't rebuild gcc47 from source, I have just upgraded

$ sudo port selfupdate
...
$ sudo port outdated
The following installed ports are outdated:
gcc45                          4.5.4_4 < 4.5.4_5         
ld64                           133.3_1 < 133.3_2         
libstdcxx                      4.7.1_6 < 4.7.1_101       
libunwind-headers              30_4 < 35.1_0

and have rebuilt the ROOT tests... Now stressMathMore works but

$ ./stressMathCore
Beta distribution                       		................ OK
Gamma distribution                      		................ OK
Chisquare distribution                  		................ OK
Normal distribution                     		................ OK
[...]
Matrix<Double32_t,5,5,MatRepSym> after read		................ OK
******************************************************************************
	Test of a Composite Object (containing Vector's and Matrices)
******************************************************************************
Test Using CINT library

Error in <TUnixSystem::DynamicPathName>: ../test/libTrackMathCoreDict[.so | .dll | .dylib | .sl | .dl | .a] does not exist in .:/opt/local/lib/root::/opt/local/lib/root/cint/cint/stl
Error in <TUnixSystem::DynamicPathName>: test/libTrackMathCoreDict[.so | .dll | .dylib | .sl | .dl | .a] does not exist in .:/opt/local/lib/root::/opt/local/lib/root/cint/cint/stl
Error Loading libTrackMathCoreDict
******************************************************************************
stressMathCore: Real Time =   3.39 seconds Cpu Time =   1.95 seconds
 ROOTMARKS = 3131.28 ROOT version: 5.34/01	tags/v5-34-01@45048
*******************************************************************************
stressMathCore Test Failed !!

I don't know if this id ROOT specific or if related to the GCC47 changes.

Notice that after the first libstdcxx fix, I installed ROOT as

$ port installed root
The following ports are currently installed:
  root @5.34.01_1+avahi+fftw3+fitsio+gcc47+graphviz+gsl+ldap+minuit2+mysql+odbc+opengl+postgresql92+pythia+python32+roofit+ruby+soversion+ssl+tmva+xml (active)

Ciao, Angelo.

[cjones051073 (Chris Jones)]

looks like one of your libraries didn't build, libTrackMathCoreDict. Did you cleanly rebuild your tests ?

[angelo.graziosi@…]

Replying to jonesc@…:

looks like one of your libraries didn't build, libTrackMathCoreDict. Did you cleanly rebuild your tests ?

I did exactly this in my ~/work directory:

$ rm -rf test tutorials/
$ rsync -av /opt/local/share/root/test/ test/
$ rsync -av /opt/local/share/root/tutorials/ tutorials/
$ cd test
$ ln -sf ../tutorials/proof
$ make all clean

the output of "make all clean" looks good, no errors nor warnings it seems...

But, "libTrackMathCoreDic" isn't a ROOT library?

[angelo.graziosi@…]

Replying to angelo.graziosi@…:

Replying to jonesc@…:

looks like one of your libraries didn't build, libTrackMathCoreDict. Did you cleanly rebuild your tests ?

I did exactly this in my ~/work directory:

$ rm -rf test tutorials/
$ rsync -av /opt/local/share/root/test/ test/
$ rsync -av /opt/local/share/root/tutorials/ tutorials/
$ cd test
$ ln -sf ../tutorials/proof
$ make all clean

the output of "make all clean" looks good, no errors nor warnings it seems...

But, "libTrackMathCoreDic" isn't a ROOT library?

Ah, discovered the culprit!

"make all clean" deletes that library!!! Indeed

make clean
make all
./stressMathCore

works!

Sorry for the noise...

[cjones051073 (Chris Jones)]

No, its not a part of the standard ROOT installation, but the test suite, e.g.

( This is a linux installation, but the same idea )

pciy /cvmfs/lhcb.cern.ch/lib/RootConfig/pro/x86_64-slc5-gcc43-opt/root/test > ls
Aclock.cxx         eventa.cxx         guiviewerLinkDef.h  stress.cxx             stressRooFit_tests.cxx     TetrisDict.cxx
AclockDict.cxx     eventb.cxx         Hello.cxx           stressEntryList.cxx    stressRooStats.cxx         TetrisDict.h
AclockDict.h       Event.cxx          HelloDict.cxx       stressFit.cxx          stressRooStats_models.cxx  Tetris.h
Aclock.h           EventDict.cxx      HelloDict.h         stressGeometry.cxx     stressRooStats_tests.cxx   Tetris.rootmap
Aclock.rootmap     EventDict.h        Hello.h             stressGraphics.cxx     stressShapes.cxx           threads.cxx
bench.cxx          Event.h            Hello.rootmap       stressGraphics.ref     stressSpectrum.cxx         TrackMathCoreDict.cxx
benchLinkDef.h     EventLinkDef.h     hsimple.cxx         stressGUI.cxx          stressTMVA.cxx             TrackMathCoreDict.h
CMakeLists.txt     eventload.cxx      hworld2.cxx         stressHepix.cxx        stressVector.cxx           TrackMathCore.h
ctorture.cxx       EventMT.cxx        hworld.cxx          stressHistoFit.cxx     TBench.cxx                 TrackMathCoreLinkDef.h
DrawTest.sh        EventMTDict.cxx    MainEvent.cxx       stressHistogram.cxx    TBenchDict.cxx             TrackMathCoreRflx.xml
dt_build.C         EventMTDict.h      Makefile            stressInterpreter.cxx  TBenchDict.h               tstring.cxx
dt_DrawTest.C      EventMT.h          Makefile.win32      stressIterators.cxx    TBench.h                   vlazy.cxx
dt_Makefile        GetWebHistogram.C  minexam.cxx         stressIterators.h      tcollbm.cxx                vmatrix.cxx
dt_MakeFiles.sh    guitest.cxx        ProofBench          stressLinear.cxx       tcollex.cxx                vvector.cxx
dt_MakeRef.C       guiviewer.cxx      QpRandomDriver.cxx  stressMathCore.cxx     test2html.cxx
dt_RunDrawTest.C   guiviewerDict.cxx  README              stressMathMore.cxx     testbits.cxx
dt_RunDrawTest.sh  guiviewerDict.h    RootIDE             stressProof.cxx        TestVectors.cxx
dt_wrap.C          guiviewer.h        RootShower          stressRooFit.cxx       Tetris.cxx

See TrackMathCoreDict.{h,cxx}

Looks like your build of the tests are failing. I would check that.

Chris

[cjones051073 (Chris Jones)]

Our posts crossed ...

[cjones051073 (Chris Jones)]

make clean usually deletes the build. that is the point ;)

[angelo.graziosi@…]

Replying to jonesc@…:

make clean usually deletes the build. that is the point ;)

Really it should delete only .o files..

libTrackMathCoreDic.so is the only .so file it deletes: libEvent.so, libEventMT.so, ..., Aclock.so, Tetris.so are not deleted!

[cjones051073 (Chris Jones)]

That is a design choice though. In all make files I work with or write 'make clean' deletes the binaries, *.a, *.so. So *really* cleans house. This isn't 'port clean' which only cleans out the port build area, but not the installed version.

Anyway, this is way way OT, so lets leave it.

[howarth@…]

See ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806 which is a report from a user on your broken gcc47 packaging.
Disabling the use of the libgcc_ext.10.4/5 stub (which contains all of the symbols in libgcc added since Apple's libgcc_s.10.4/5)
and not using the libstdc++ which FSF gcc builds is a really bad idea. Have you actually tried running....

make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"

on a MacPorts gcc47 build to see how many regressions you have introduced by these radical changes.
I would imagine at the very least you have totally broken the libgomp support in FSF gcc.

[howarth@…]

Note that for comparison, the testsuite results for FSF gcc 4.7.2 from a normal build can be found at...

​http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02291.html
​http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02247.html
​http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02248.html

for builds targeting x86_64-apple-darwin10.8.0, i386-apple-darwin10.8.0 and x86_64-apple-darwin12.2.0.
Also a lot of thought went into the design of the libgcc_ext stubs by Iain Sandoe to insure that the newer
features in FSF gcc would be function properly. Butchering the gcc47 package to work around the breakage of
gcj on darwin9 and earlier seems really extreme.

[jeremyhu (Jeremy Huddleston Sequoia)]

howarth, we *ARE* using the libstdc++ from FSF gcc

[jeremyhu (Jeremy Huddleston Sequoia)]

And we're not disabling the use of the libgcc_ext.10.4/5 stub, although my comment in there is that we probably could.

[howarth@…]

Please make sure you don't degrade the FSF gcc testsuite results by disabling libgcc_ext if you do so. In particular one reason for
using FSF gcc would be to utilize libgomp (whose functionality isn't available in clang yet).
Also, per your comments in...

​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806#c8

and the fact you are using binary distributions, how will you handle the following situation?
1) The user installs a MacPorts package prebuilt against gcc48
2) The user also has gcc47 installed.

What prevents the binaries built against the libstdc++ from gcc48 from running against the libstdc++ from gcc47.
In attempting to collapse the number of libstdc++'s installed to a single one, how do you insure that new features added
in c++ for a newer FSF gcc release are properly supported in the libstdc++ used? If you are using a single libstdc++, will
it always be generated from the newest gcc4x package in MacPorts? If so, will it really be compatible when used with
c++ code generated from the older FSF gcc4x packages? This seems like an awful lot of assumptions on backward compatibilty
would have to be made.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to howarth@…:

Please make sure you don't degrade the FSF gcc testsuite results by disabling libgcc_ext if you do so. In particular one reason for
using FSF gcc would be to utilize libgomp (whose functionality isn't available in clang yet).

Jack, I've already told you that we haven't disabled libgcc_ext. Also, if we do, we will of course test beforehand.

Also, per your comments in...

​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806#c8

and the fact you are using binary distributions, how will you handle the following situation?
1) The user installs a MacPorts package prebuilt against gcc48
2) The user also has gcc47 installed.

If the user installs a Macports package built against gcc48, then they need to have libstdcxx-devel installed, and that will be handled by the dependency tree. The package will have a depends_lib on gcc48 which has a depends_lib on libstdcxx-devel. I don't see the problem.

What prevents the binaries built against the libstdc++ from gcc48 from running against the libstdc++ from gcc47.

The fact that they can't both be installed at the same time. If they have gcc48 on their system, they can't have gcc47's libstdc++ because gcc48 depends on libstdcxx-devel whereas gcc47 can use libstdcxx or libstdcxx-devel

In attempting to collapse the number of libstdc++'s installed to a single one, how do you insure that new features added
in c++ for a newer FSF gcc release are properly supported in the libstdc++ used? If you are using a single libstdc++, will
it always be generated from the newest gcc4x package in MacPorts?

Yes. Look at the Portfiles. It is always generated from the newest gcc4x packages.

If so, will it really be compatible when used with
c++ code generated from the older FSF gcc4x packages?

It's supposed to be.

This seems like an awful lot of assumptions on backward compatibilty
would have to be made.

Yes, we make such assumptions across all our packages. We don't expect that upstream will break backwards compatibility, and if they do, we expect that they will do it in a logical manner.

[howarth@…]

Replying to jeremyhu@…:

And we're not disabling the use of the libgcc_ext.10.4/5 stub, although my comment in there is that we probably could.

This statement isn't true. Use of the no-runtime-stubs.patch during the limited c++ bootstrap to build libstdc++-v3 is
certain to prevent the config.h in ./x86_64-apple-darwin11.4.2/[i386/,]libstdc++-v3/config.h from having...

#define HAVE_TLS 1

The use of the no-run-time-stubs is bound to destroy support for additional features like emutls that require those additional
symbols.

[howarth@…]

IMHO, I think the only way to achieve a fully functional libstdc++-v3 split-off would be to abandon the no-runtime-stubs.patch
and instead create an additional libgcc_ext split-off which is kept synchronized to the latest release. It might be tricky since
libgcc_ext.10.4/5 are stubs designed to pick up all the symbols not in Apple's libgcc_10.4/5 and thus libgcc_s would have to
be in the split off as well.

[jeremyhu (Jeremy Huddleston Sequoia)]

r98493 ... added missing link to libgcc_eh

Jack, in the future, please open new tickets for new issues...