[MacPorts] #58442: clang-7, 8.0 - seg. faults when used as assembler with assertions variant active.

MacPorts noreply at macports.org
Fri May 10 08:15:45 UTC 2019


#58442: clang-7,8.0 - seg. faults when used as assembler with assertions variant
active.
----------------------------------+--------------------
  Reporter:  mouse07410           |      Owner:  (none)
      Type:  defect               |     Status:  new
  Priority:  Normal               |  Milestone:
 Component:  ports                |    Version:
Resolution:                       |   Keywords:
      Port:  clang-7.0 clang-8.0  |
----------------------------------+--------------------

Comment (by cjones051073):

 > > You are using a non-standard variant which counts as a special build
 >
 > Since when did "non-default" become "non-standard"?

 To mind thinking, they have always been the same thing.

 >
 > Are you testing your ports for all the variants you define/support? Or
 only the default one?
 >

 The non-default variants are generally not as well tested as the default
 ones. In the case of the clang ports I cannot comment on if the maintainer
 tried any of them or not. Its really up to port maintainers to decide how
 well, or not, they test non-default variants. They aren't tested in any
 form as part of either the automatic builds in PRs, or by the buildbots.

 >
 > >
 > > The build bots have all built gcc9 and gcc10 fine on macOS10.7+
 >
 > MacOS **10.7**?  Are you validating under 10.14.x using Xcode-10.2.x? If
 not, I'd say that explains why you aren't catching this crash. Xcode-10.2
 is quite different in what it allows and what it fails than the previous
 versions, at least in my experience.

 That is not what I said. I said the *buildbots* have successfully built
 gcc9 on *all* platforms from 10.7 upwards. That means all the way to
 10.14. And just for the record, my primary machines here are 10.14 and
 10.13 Xcode 10.2, and I have VMs going back to 10.6. When I submitted the
 recent gcc9 update I did test it across the board first.

 >
 > Also, as I'm working with crypto code that tries to squeeze an extra bit
 of performance by utilizing inline assembly (I'm one of the maintainers of
 Crypto++ https://en.wikipedia.org/wiki/Crypto%2B%2B library), I'm trying
 to make sure it compiles with all the compilers available on MacOS. I
 noticed that the only way to get Macports GCC to compile code with inline
 assembly is to make it invoke Xcode assembler via {{{-Wa,-q}}}. We're also
 using {{{export AS_INTEGRATED_ASSEMBLER=1}}}.
 > I'd just stick with Xcode, but it's GCC sucks even more, and it's very
 outdated besides. So, for a decent GCC have to use Macports port.

 macOS does not have have gcc any more, in any form. Hasn't for years. Yes,
 it has a command that is called g++, but it aint GNU GCC. Its just a
 wrapper around clang.

 {{{
 Titan ~/Projects/MacPorts/ports > which g++
 /usr/bin/g++
 Titan ~/Projects/MacPorts/ports > g++ --version
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Apple LLVM version 10.0.0 (clang-1000.11.45.5)
 Target: x86_64-apple-darwin17.7.0
 Thread model: posix
 InstalledDir:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 }}}

 If you need GNU GCC, there is no option but to use an external source,
 like MacPorts.

-- 
Ticket URL: <https://trac.macports.org/ticket/58442#comment:44>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list