graphite2 fails to build for ppc on 10.6.8 (Rosetta): unrecognized command line option '-mfpmath=sse'

[barracuda156]

:info:build g++-mp-7: error: unrecognized command line option '-mfpmath=sse'
:info:build g++-mp-7: error: unrecognized command line option '-msse2'; did you mean '-misel'?
:info:build make[2]: *** [src/CMakeFiles/graphite2.dir/call_machine.cpp.o] Error 1

[ 29%] Built target graphite2-file
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphite2/graphite2/work/build'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphite2/graphite2/work/build'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_graphite2/graphite2/work/build" && /usr/bin/make -j4 -w all VERBOSE=ON 
Exit code: 2
Error: Failed to build graphite2: command execution failed

[barracuda156]

The problem lies here:

Use -mfpmath=sse -msse2 only on Intel.
https://github.com/silnrsi/graphite/pull/44
--- src/CMakeLists.txt.orig	2018-08-15 00:38:09.000000000 -0500
+++ src/CMakeLists.txt	2018-10-01 12:46:50.000000000 -0500
@@ -136,9 +136,14 @@
 
 if  (${CMAKE_SYSTEM_NAME} STREQUAL "Darwin")
     set_target_properties(graphite2 PROPERTIES
-        COMPILE_FLAGS   "-Wall -Wextra -Wno-unknown-pragmas -Wimplicit-fallthrough -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-rtti -fno-exceptions -fvisibility=hidden -fvisibility-inlines-hidden -mfpmath=sse -msse2"
-        LINK_FLAGS      "-nodefaultlibs"
+        COMPILE_FLAGS   "-Wall -Wextra -Wno-unknown-pragmas -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-rtti -fno-exceptions -fvisibility=hidden -fvisibility-inlines-hidden"
         LINKER_LANGUAGE C)
+    if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86|i.86")
+        add_definitions(-mfpmath=sse -msse2)
+    endif (${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86|i.86")
+    if (${CMAKE_CXX_COMPILER_ID} MATCHES "Clang")
+        add_definitions(-Wimplicit-fallthrough)
+    endif (${CMAKE_CXX_COMPILER_ID} MATCHES "Clang")
     target_link_libraries(graphite2 c)
     include(Graphite)
     nolib_test(stdc++ $<TARGET_SONAME_FILE:graphite2>)

These flags should be only used for Intel, however Cmake applies them nevertheless, unaware of Rosetta case.

[kencu (Ken)]

that part of the CMakeLists.txt is actually added by MacPorts, to allow building on non-Intel processors.

Look in the Port directory for the patch MacPorts added.

Perhaps you can tweak the existing patch to change it to include the build architecture in the logic, as that might be an improvement that could be accepted into the ports tree.

[ryandesign (Ryan Carsten Schmidt)]

Upstream did ​accept that patch so they might accept improvements to it. However I'm not sure that any changes are needed in graphite2; the changes may be needed in the cmake portgroup.

Seems like during your build CMAKE_SYSTEM_PROCESSOR had the value of the build machine's processor, even though you were wanting to cross-compile for PowerPC on an Intel machine. According to ​the documentation, CMAKE_SYSTEM_PROCESSOR should have the correct value for cross-compiling if we use a CMAKE_TOOLCHAIN_FILE, but as far as I know nothing in MacPorts makes any attempt to do that. If you want to improve cross-compilation support for cmake projects in MacPorts, that's probably what to look at. I would guess that any successful use of a toolchain file would also require doing separate builds for separate architectures, which would mean using the muniversal portgroup.

Attempting to make the cmake portgroup always include the muniversal portgroup would probably have adverse consequences for at least a handful of ports that already do successful universal builds, so this might be the kind of fix that would have to be introduced in a new version of cmake portgroup (we already have 1.0 and 1.1 so maybe 1.2) and ports would opt into that new version over time.

I'm not sure how common it is for cmake projects to make decisions based on CMAKE_SYSTEM_PROCESSOR. If it's uncommon, maybe making changes in individual affected ports like graphite2 is better than trying to craft a general solution that can go in the portgroup.

[kencu (Ken)]

A cmake toolchain file looks like a more-or-less similar beast to the meson cross-file system that I installed for the meson PortGroup to use.

slightly different syntax.

Not sure just what wreckage might ensue from trying to use that with cmake -- lots of issues are easy to imagine.

[barracuda156]

Replying to kencu:

that part of the CMakeLists.txt is actually added by MacPorts, to allow building on non-Intel processors.

Look in the Port directory for the patch MacPorts added.

Yes, I saw that, above is actually a quote from the patch. (As a quick one-time fix I replaced x86 with arm in it, so that wrong flags do not get applied, and graphite2 built.)

Perhaps you can tweak the existing patch to change it to include the build architecture in the logic, as that might be an improvement that could be accepted into the ports tree.

Yeah, I should do a proper fix and new diff file. In effect we just need to remove those flags.

[barracuda156]

Replying to ryandesign:

I'm not sure how common it is for cmake projects to make decisions based on CMAKE_SYSTEM_PROCESSOR. If it's uncommon, maybe making changes in individual affected ports like graphite2 is better than trying to craft a general solution that can go in the portgroup.

I have encountered such behavior of Cmake several times today. As another example: #64528

Since Cmake does not accept normal --build= etc. triple, getting through these errors on case-by-case basis doesn't appear anywhere optimal. General solution would be great.

[kencu (Ken)]

In addition, in x265, the cmake script assumes there will be nobody building on ppc32 any more, and ignores it.

set(POWER_ALIASES ppc64 ppc64le)

I will have to look again sometime at how we can build proper universal ports using cmake on Intel for the arm processor, given this. Works somehow.

[kencu (Ken)]

Replying to barracuda156:

Yes, I saw that, above is actually a quote from the patch.

You are 100% correct. I did not look carefully enough at your post to notice you were quoting the patch...

[barracuda156]

Replying to kencu:

I will have to look again sometime at how we can build proper universal ports using cmake on Intel for the arm processor, given this. Works somehow.

Building universal might become more popular now with Apple M, so we may hope more developers gonna keep such possibility in mind. (And it probably won't be too hard to add ppc/ppc64 from our end then.)

By the way, it is possible in principle to move from one building system to another, or that is too much of a pain?

[ryandesign (Ryan Carsten Schmidt)]

Which build system(s) a project supports is up to its developers. Usually a project only supports one build system. Sometimes, when a project transitions from one build system to another, they support both for a time.

[kencu (Ken)]

Replying to barracuda156:

Building universal might become more popular now with Apple M, so we may hope more developers gonna keep such possibility in mind.

I have built hundreds and hundreds, maybe thousands, of ports universal for M1 and Intel, including using cmake. I was on a terror at the beginning and just went wild fixing them to build universal.

Most of those just used multiple arch flags and so it was fairly trivial. But some of them used muniversal I think, and somehow they worked. Just have to go back and look at details of how.

It was not with a toolchain file. Probably (I vaguely recall) we just patched and reinplaced the desired processor into the CMakeLists.txt.

[barracuda156]

Replying to kencu:

I have built hundreds and hundreds, maybe thousands, of ports universal for M1 and Intel, including using cmake. I was on a terror at the beginning and just went wild fixing them to build universal. Most of those just used multiple arch flags and so it was fairly trivial. But some of them used muniversal I think, and somehow they worked. Just have to go back and look at details of how. It was not with a toolchain file. Probably (I vaguely recall) we just patched and reinplaced the desired processor into the CMakeLists.txt.

This sounds inspiring! Thanks.

I will return to building universal in a while. Probably not so much to x86_64+ppc, since that may not have realistic use cases, but at least to ppc+ppc64. (For now, I wanna first fix linker problem which causes some ports to fail on 10.6.8 and gcc10 to fail on 10.6 PPC.)

[barracuda156]

Replying to ryandesign:

Upstream did ​accept that patch so they might accept improvements to it. However I'm not sure that any changes are needed in graphite2; the changes may be needed in the cmake portgroup.

Seems like during your build CMAKE_SYSTEM_PROCESSOR had the value of the build machine's processor, even though you were wanting to cross-compile for PowerPC on an Intel machine. According to ​the documentation, CMAKE_SYSTEM_PROCESSOR should have the correct value for cross-compiling if we use a CMAKE_TOOLCHAIN_FILE, but as far as I know nothing in MacPorts makes any attempt to do that. If you want to improve cross-compilation support for cmake projects in MacPorts, that's probably what to look at. I would guess that any successful use of a toolchain file would also require doing separate builds for separate architectures, which would mean using the muniversal portgroup.

Attempting to make the cmake portgroup always include the muniversal portgroup would probably have adverse consequences for at least a handful of ports that already do successful universal builds, so this might be the kind of fix that would have to be introduced in a new version of cmake portgroup (we already have 1.0 and 1.1 so maybe 1.2) and ports would opt into that new version over time.

I'm not sure how common it is for cmake projects to make decisions based on CMAKE_SYSTEM_PROCESSOR. If it's uncommon, maybe making changes in individual affected ports like graphite2 is better than trying to craft a general solution that can go in the portgroup.

Is there any reason to use CMAKE_SYSTEM_PROCESSOR and not CMAKE_OSX_ARCHITECTURES there? With the latter everything works correctly on 10.6.8 Rosetta.