[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