[MacPorts] #38732: gcc48 is broken by configure-timespec.patch
MacPorts
noreply at macports.org
Wed Apr 10 09:14:35 PDT 2013
#38732: gcc48 is broken by configure-timespec.patch
------------------------+-------------------
Reporter: howarth@… | Owner: mww@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.1.3
Resolution: | Keywords:
Port: gcc48 |
------------------------+-------------------
Comment (by jeremyhu@…):
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).
--
Ticket URL: <https://trac.macports.org/ticket/38732#comment:12>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list