[MacPorts] #65153: nss fails to build for x86_64 on 10.6.8 when forcing the build to use gcc11 instead of the default clang compiler: no such instruction: `pclmulqdq $16, %xmm2, %xmm0'

MacPorts noreply at macports.org
Mon Nov 7 01:26:40 UTC 2022


#65153: nss fails to build for x86_64 on 10.6.8 when forcing the build to use gcc11
instead of the default clang compiler: no such instruction: `pclmulqdq $16,
%xmm2,%xmm0'
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  (none)
  barracuda156           |
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.2
Resolution:              |   Keywords:  x86_64, snowleopard,
      Port:  nss         |  nonstandard_build
-------------------------+-------------------------------------------------

Comment (by kencu):

 these newer AVX assembly instructions are unknown to the 2004-vintage
 assembler that comes with cctools, or that comes with the system.

 To get around this, MacPorts cctools will use a newish clang to assemble
 instead, if it is available. So we dealt with this error some years ago.

 So to fix this, use MacPorts cctools assembler, and make sure a newish
 clang like clang-11 is installed.


 Regarding:

 > In my experience, Clang requires flags -maesni -mpcmul for code like
 this. GCC, in addition to that, requires a different assembler, like env
 variable AS_INTEGRATED_ASSEMBLER=1 and CFLAGS += -Wa,-q -Wa,-march=native
 (re. -march: maybe -maesni -mpcmul instead).

 None of that is needed on MacPorts, because of the above modification we
 made to cctools.

 Regarding:

 > In my humble opinion, the baseline case should be using Apple own
 assembler as it exists for each OS. Using clang may be desirable generally
 on Intel, but every system should be able to function with OS cctools +
 Macports cctools + gcc.

 Then you would have to instead find a way to disable that troublesome
 assembly on older systems where the system toolchain can't understand it.
 Some ports have done that. For the general case, MacPorts decided to go a
 different way, and support the assembly, instead of that.

 Summary:

 1. on Intel systems, blacklist all clangs that don't support that
 assembly. A little trial and error should show you, but you can google the
 details of the which-clang-supported-which assembly-instructions support
 if you want. Let the build build with clang. All will be well.

 2. On other Intel systems where gcc is the default compiler (10.4 and 10.5
 Intel at present), you have to have a new enough clang installed as above
 that can understand that assembly. You may need to "depends_build-append"
 this compiler.

 3. On PPC, you should be fine and this file should not be part of the
 build anyway. If it is part of the build, might have to either patch it
 out or do as per point 2.

 4. On arm, the only clangs that work are already new enough to handle this
 assembly, so there should be no issues at present.

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


More information about the macports-tickets mailing list