ninja fails to build universal

[ryandesign (Ryan Carsten Schmidt)]

g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags

ninja +universal is eventually required for wine.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Could the ​muniversal PG be used to fixe the problem?

[kencu (Ken)]

why does ninja need to be universal?

[ryandesign (Ryan Carsten Schmidt)]

All ports should support the universal variant if possible. If not possible, the variant should be disabled. Don't leave broken variants in ports.

But specifically in this case, ninja is eventually a dependency of wine, which requires 32-bit support.

[kencu (Ken)]

Yeah but as ninja is just a build program, like gmake, and nothing in wine links against it you should be able to build 32bit wine with any version of ninja, 64bit or 32bit, and just

depends_skip_archcheck-append ninja

or maybe there's more to ninja I don't know about.

[ryandesign (Ryan Carsten Schmidt)]

True. If ninja does not install libraries, it should use installs_libs no, which will automatically skip the architecture check.

[kencu (Ken)]

it should use installs_libs no, which will automatically skip the architecture check.

did that part for you just now.

[Marcus Calhoun-Lopez <marcuscalhounlopez@…>]

In b5e154f65aa59c92d42dbfa3cc9a9679f0fbd268/macports-ports (master):

ninja: allow universal build on older systems

Fixes #56494

[kencu (Ken)]

On BigSur Intel/arm64 ninja builds fine +universal without the muniversal PG, but fails with it added unless additional workarounds are added to allow the muniversal PG to function.

x ./
x ./+STATE
x ./+PORTFILE
x ./+CONTENTS
x ./+DESC
x ./+COMMENT
x ./opt/
x ./opt/local/
x ./opt/local/bin/
x ./opt/local/etc/
x ./opt/local/share/
x ./opt/local/share/doc/
x ./opt/local/share/doc/ninja/
x ./opt/local/share/doc/ninja/README.md
x ./opt/local/share/doc/ninja/COPYING
x ./opt/local/share/doc/ninja/CONTRIBUTING.md
x ./opt/local/etc/bash_completion.d/
x ./opt/local/etc/bash_completion.d/ninja
x ./opt/local/bin/ninja
--->  Cleaning ninja
--->  Removing work directory for ninja
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

% file /opt/local/bin/ninja
/opt/local/bin/ninja: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/opt/local/bin/ninja (for architecture x86_64):	Mach-O 64-bit executable x86_64
/opt/local/bin/ninja (for architecture arm64):	Mach-O 64-bit executable arm64

I wonder if they cleaned up their build since this ticket was opened, and if we might not need the muniversal PG any longer.

If we don't need it for older systems or i386/x86_64, that would make things simpler to build ninja universal, as it just builds without any fuss on BigSur.

[kencu (Ken)]

After removing the muniversal PortGroup, ninja currently has no problems at all building +universal on 10.6.8 using the default compiler setup, which is (presently) clang-9.0 and libcxx.

[kencu (Ken)]

Likewise, after removing the muniversal PortGroup, ninja currently has no problems at all building +universal on 10.6.8 using the defacto bootstrap compiler clang-3.4 and libcxx.

[kencu (Ken)]

It is looking to me that the muniversal PortGroup is likely no longer needed, and if we remove it, our current issues building it universal on BigSur will disappear.

[ryandesign (Ryan Carsten Schmidt)]

Per the description of this ticket, the issue occurred when building with gcc-4.2. Presumably llvm-gcc42 would also be affected. Assuming that issue remains, we would have to blacklist those compilers at least when building universal if we wanted to remove the muniversal portgroup or else we would have to patch the build system so that it does not use multiple arch flags together with -E, -S, -save-temps or -M.

[kencu (Ken)]

II think the same error -E, -S, -save-temps and -M options are not allowed with multiple -arch flags occurs with clang.

They probably aren't pulling that any more.

But the only systems I have left that try to build c++ software with gcc-4.2 are 10.4 and 10.4, and I haven't yet bothered to spin those up to check this yet.

Not that of those systems can really build universal anyway anymore.

[kencu (Ken)]

Nope -- clang ate that, but gcc-4.2 does not:

--->  Configuring ninja
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ninja/ninja/work/ninja-1.10.2" && /usr/bin/python configure.py --with-python=/usr/bin/python --bootstrap --verbose 
g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
bootstrapping ninja...
"./src/inline.sh" kBrowsePy < ./src/browse.py > build/browse_py.h
ccache /usr/bin/g++-4.2 -MMD -MT build/browse.o -MF build/browse.o.d -g -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="/usr/bin/python"' -O2 -DNDEBUG -DNINJA_HAVE_BROWSE -I. -pipe -Os -arch x86_64 -arch i386 -pipe -Os -arch x86_64 -arch i386 -c ./src/browse.cc -o build/browse.o
when running:  ccache /usr/bin/g++-4.2 -MMD -MT build/browse.o -MF build/browse.o.d -g -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="/usr/bin/python"' -O2 -DNDEBUG -DNINJA_HAVE_BROWSE -I. -pipe -Os -arch x86_64 -arch i386 -pipe -Os -arch x86_64 -arch i386 -c ./src/browse.cc -o build/browse.o
Traceback (most recent call last):
  File "configure.py", line 470, in <module>
    objs += cxx('browse', order_only=built('browse_py.h'))
  File "configure.py", line 287, in cxx
    return n.build(built(name + objext), 'cxx', src(name + '.cc'), **kwargs)
  File "configure.py", line 169, in build
    self._run_command(self._expand(cmd, local_vars))
  File "configure.py", line 194, in _run_command
    subprocess.check_call(cmdline, shell=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subprocess.py", line 462, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'ccache /usr/bin/g++-4.2 -MMD -MT build/browse.o -MF build/browse.o.d -g -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="/usr/bin/python"' -O2 -DNDEBUG -DNINJA_HAVE_BROWSE -I. -pipe -Os -arch x86_64 -arch i386 -pipe -Os -arch x86_64 -arch i386 -c ./src/browse.cc -o build/browse.o' returned non-zero exit status 1
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ninja/ninja/work/ninja-1.10.2" && /usr/bin/python configure.py --with-python=/usr/bin/python --bootstrap --verbose 
Exit code: 1

vs clang:

--->  Configuring ninja
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ninja/ninja/work/ninja-1.10.2" && /usr/bin/python configure.py --with-python=/usr/bin/python --bootstrap --verbose 
warning: /opt/local/bin/ranlib: archive library: build/libninja.a will be fat and ar(1) will not be able to operate on it
bootstrapping ninja...
"./src/inline.sh" kBrowsePy < ./src/browse.py > build/browse_py.h
ccache /opt/local/bin/clang++-mp-9.0 -MMD -MT build/browse.o -MF build/browse.o.d -g -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="/usr/bin/python"' -O2 -DNDEBUG -DNINJA_HAVE_BROWSE -I. -pipe -Os -arch x86_64 -arch i386 -pipe -Os -stdlib=libc++ -arch x86_64 -arch i386 -c ./src/browse.cc -o build/browse.o

so indeed gcc-4.2 doesn't like it.

Unfortunately blacklisting gcc-4.2 is not really an option, as that is what has to be used on certain systems.

[ryandesign (Ryan Carsten Schmidt)]

Well as I said it would only need to be blacklisted if the universal variant is selected. Alternately, the muniversal portgroup could be included only if the compiler is old gcc/llvm-gcc. Assuming that this was the only reason why the muniversal portgroup was being used.

[Ken <21211439+kencu@…>]

In d35329911f6eda3dddca1410d7374bea15730402/macports-ports (master):

ninja: fix cross-arch universal build (​https://github.com/macports/macports-ports/pull/12122)

Apple's gcc compilers do not allow dependency file generation
when multiple arch flags are used

This resulted in the muniversal portgroup being used to repair the
build of ninja several years ago, however this has it's own
issues by not allowing a cross-arch universal binary to be built,
due to the way the ninja bootstraps itself during compilation.

if we strip the (unnecessary) dependency file generation by removing
the dependency flags, then the muniversal PortGroup is no longer
needed and the cross-arch universal build can succeed without
using the muniversal portgroup.

see: ​https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
see: 701e7b2597f2da954a390b1b63aa90d6f7aaba20/macports-base
see: #56494

closes: #62259