nettle @3.5.1: Build failure on PowerPC due to calling in clang-8.0 as compiler.

[SerpentChris (Chris Calderon)]

Attempting to install MPlayer on Mac OS X 10.5.8 fails with the following message:

--->  Computing dependencies for MPlayer....................................................................................
Error: Cannot install clang-8.0 for the arch 'powerpc' because
Error: its dependency libxml2 does not build for the required arch by default
Error: and the configured universal_archs 'i386 ppc' are not sufficient.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port MPlayer failed

[kencu (Ken)]

There are some hiccups with the new MacPorts 2.6.x series and PowerPC that we will be working through over the coming while. As you know, it's not a primary platform for MacPorts to support, but nonetheless, there are sufficient folks around here interested in the platform to work on this.

Apologies for the present situation.

[jmroot (Joshua Root)]

Please show the output of port rdeps MPlayer and maybe also port -d install MPlayer so we can see which port is actually depending on clang-8.0.

[kencu (Ken)]

$ port rdeps MPlayer
The following ports are dependencies of MPlayer @1.3.0_4:
  xz
    libiconv
      gperf
    gettext
      ncurses
  pkgconfig
  yasm
  apple-gcc42
    ld64
      ld64-127
        libmacho-headers
        libunwind-headers
        llvm-3.3
          libffi
          perl5
            perl5.28
              db48
              gdbm
                readline
          llvm_select
    cctools
    gcc_select
  jpeg
  openjpeg15
    autoconf
    automake
    libtool
      xattr
        unzip
    libpng
      zlib
    tiff
      zstd
        lz4
    lcms2
    jbigkit
  lame
    legacy-support
  libmad
  gnutls
    gtk-doc
      glib2
        libxml2
          icu
        pcre
          bzip2
          libedit
        python27
          expat
          openssl
          sqlite3
          python_select
          python2_select
      libxslt
      docbook-xml
        xmlcatmgr
        docbook-xml-4.1.2
          docbook-xml-4.2
        docbook-xml-4.3
        docbook-xml-4.4
        docbook-xml-4.5
        docbook-xml-5.0
      docbook-xsl-nons
      itstool
        gawk
        py27-libxml2
      python37
        python3_select
      py37-anytree
        py37-setuptools
        py37-six
      py37-lxml
      py37-pygments
        pygments_select
      py37-mock
    gcc6
      gmp
      isl
      libmpc
        mpfr
      libgcc6
        libgcc7
    libidn2
      libunistring
        texinfo
          help2man
            p5.28-locale-gettext
    libtasn1
    p11-kit
      curl-ca-bundle
    nettle
      clang-8.0
        cmake
          curl
            libpsl
          libarchive
            lzo2
          libuv
          libgcc
        clang-3.7
          clang-3.4
            llvm-3.4
            clang_select
          llvm-3.7
            libcxx
        libomp
        llvm-8.0
          xar
  libogg
  libopus
  libtheora
    libvorbis
  liboil
  libass
    fribidi
    fontconfig
      freetype
      ossp-uuid
  rtmpdump

nettle wants clang-8.0 on PPC:

$ port info nettle
nettle @3.5.1 (devel, crypto)
Variants:             universal

Description:          Nettle is a cryptographic library that is designed to fit easily in more or less any context: In crypto
                      toolkits for object-oriented languages (C++, Python, Pike, ...), in applications like LSH or GNUPG, or
                      even in kernel space. It tries to solve a problem of providing a common set of cryptographic algorithms
                      for higher-level applications by implementing a context-independent set of cryptographic algorithms. In
                      that light, Nettle doesn't do any memory allocation or I/O, it simply provides the cryptographic
                      algorithms for the application to use in any environment and in any way it needs.
Homepage:             https://www.lysator.liu.se/~nisse/nettle/

Build Dependencies:   autoconf, automake, libtool, clang-8.0
Library Dependencies: gmp
Platforms:            darwin
License:              LGPL-2.1+
Maintainers:          Email: ryandesign@macports.org, GitHub: ryandesign
                      Policy: openmaintainer

and in nettle

# error: invalid instruction mnemonic 'sha1rnds4'
compiler.blacklist-append  *gcc-3.* *gcc-4.* {clang < 500} \
                           macports-clang-3.4 macports-clang-3.7
compiler.fallback-append   macports-clang-8.0 macports-clang-7.0

[kencu (Ken)]

As mentioned on the mailing list, on PPC this block:

compiler.blacklist-append  *gcc-3.* *gcc-4.* --ETC

should lead to macports-gcc-6 and macports-gcc-7, but doesn't.

[jmroot (Joshua Root)]

So what's happening is that get_min_gcc returns "none" unless configure.cxx_stdlib is macports-libstdc++, and configure.cxx_stdlib only has that value if compiler.cxx_standard is 2011 or greater. Basically nettle has blacklisted all the usable compilers on some platforms. Not sure what the best approach would be here.

Setting compiler.cxx_standard would be an obvious workaround even if it's not properly needed.

[kencu (Ken)]

Well done ! BTW, that particular gcc blacklisting construct is quite widely used in Portfiles.

[kencu (Ken)]

I'm thinking shouldn't the gcc compiler needed drive the choice of stdlib, rather than the other way around?

[jmroot (Joshua Root)]

Because compiling C++ with a different stdlib than everything else is a Really Bad Idea, no it shouldn't. But it's probably a good idea to let the macports-gccs be compilers of last resort on ppc anyway.

What's the situation like on Leopard/Intel BTW? Is macports-clang a viable choice there?

[jmroot (Joshua Root)]

I think something like the attached is a decent approach until base is changed.

[kencu (Ken)]

that's what I've been adding, but I found I often had to prepend it (and use first gcc6, which is still more reliable and much more widely tested on PPC).

[kencu (Ken)]

there has never been a problem mixing libstdc++ and macports-libstdc++ noted in the three years we've been doing it, although i'm aware of the theoretical issues. Whenever we call in macports-gcc, we switch to the newer stdlib automstically ( but in ABI 4 compat mode).

On 10.5 Intel Leopard, I'm still building. It should , if possible, be treated like 10.6; I have clang-7.0 working there now, and was going to start on clang-8.0 and further soon. It should have all intel universal archs, and (I'm 99% sure) should default to libc++ too, eventually. If that's not too confusing with the os.major tests we have everywhere.

[jmroot (Joshua Root)]

Ah of course, the clangs need to be excluded too. I guess get_min_clang should return none when building for ppc as well.

Future work is all well and good, but what will work on a standard installation of 10.5 on Intel right now?

[kencu (Ken)]

For a starting position, I plan to set my system up defaulting to libc++ but peaking out at clang-7.0 in compiler selection, with universal archs set to all Intel (ie as close to 10.6 as can be had at present). Once I fix clang-8.0, it will be identical to 10.6. I will let you know how that goes, but I expect success.

For the current user using defaults, there will be many errors ( Riccardo has pointed out the errors in cmake, and texlive-bin, and several other ports, trying to build with gcc 7 on Intel --- I don't plan to spend time fixing any of those errors as I see that as wasted effort right now).

[ryandesign (Ryan Carsten Schmidt)]

Please make whatever changes to the port are necessary. I have not been involved in any of the previous compiler blacklist additions to this port.

[jmroot (Joshua Root)]

In 9aae36adae4380ecea8aeadaa9e3dbc3baaf5dbf/macports-ports (master):

nettle: fix compiler selection on ppc

Closes: #59195