#36093 closed defect (fixed)
libstdcxx can't resolve ___emutls_get_address
Reported by: | angelo.graziosi@… | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | High | Milestone: | |
Component: | ports | Version: | 2.1.2 |
Keywords: | Cc: | cjones051073 (Chris Jones), ryandesign (Ryan Carsten Schmidt) | |
Port: | libstdcxx |
Description
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.
Attachments (3)
Change History (38)
Changed 12 years ago by angelo.graziosi@…
Attachment: | root-main.log.bz2 added |
---|
Changed 12 years ago by angelo.graziosi@…
Attachment: | upgrade_outdated.out.bz2 added |
---|
comment:1 follow-up: 2 Changed 12 years ago by 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
comment:2 Changed 12 years ago by 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
comment:3 follow-up: 4 Changed 12 years ago by 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
comment:4 Changed 12 years ago by 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 rootIt 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.
comment:5 Changed 12 years ago by 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
comment:6 follow-up: 7 Changed 12 years ago by 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
comment:7 Changed 12 years ago by 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.othe missing symbol is something that should be provided by the gcc 4.7 libstdc++ I think.
Chris
comment:8 follow-ups: 9 10 Changed 12 years ago by 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
comment:9 Changed 12 years ago by 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
comment:10 Changed 12 years ago by 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
comment:11 follow-up: 18 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Owner: | changed from macports-tickets@… to jeremyhu@… |
---|---|
Port: | libstdcxx added |
Status: | new → assigned |
Angelo, please post the output of:
nm -m /opt/local/lib/libstdc++.6.dylib
Changed 12 years ago by angelo.graziosi@…
Attachment: | nm_libstdcxx.out.bz2 added |
---|
the output of "nm -m /opt/local/lib/libstdc++.6.dylib"
comment:12 Changed 12 years ago by 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
comment:13 Changed 12 years ago by 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...
comment:14 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Priority: | Normal → High |
---|
comment:15 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Summary: | ROOT is broken after GCC47 upgrade → libstdcxx can't resolve ___emutls_get_address |
---|
I have a fix that looks good ... just waiting on one machine to finish building so I can test it there...
comment:17 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:18 Changed 12 years ago by 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.
comment:19 follow-up: 20 Changed 12 years ago by cjones051073 (Chris Jones)
looks like one of your libraries didn't build, libTrackMathCoreDict. Did you cleanly rebuild your tests ?
comment:20 follow-up: 21 Changed 12 years ago by 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?
comment:21 Changed 12 years ago by 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 cleanthe 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...
comment:22 Changed 12 years ago by 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
comment:24 follow-up: 25 Changed 12 years ago by cjones051073 (Chris Jones)
make clean usually deletes the build. that is the point ;)
comment:25 Changed 12 years ago by 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!
comment:26 Changed 12 years ago by 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.
comment:27 Changed 12 years ago by 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.
comment:28 Changed 12 years ago by 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.
comment:29 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
howarth, we *ARE* using the libstdc++ from FSF gcc
comment:30 follow-up: 33 Changed 12 years ago by 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.
comment:31 follow-up: 32 Changed 12 years ago by 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.
comment:32 Changed 12 years ago by 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.
comment:33 Changed 12 years ago by 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.
comment:34 Changed 12 years ago by 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.
comment:35 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
r98493 ... added missing link to libgcc_eh
Jack, in the future, please open new tickets for new issues...
main log