m4 @1.4.19+universal: configure: error: Cannot find a type to use in place of socklen_t

[FaradayLight (Faraday Light)]

M4 failed to configure reporting the following error:

Error: Failed to configure m4: configure failure: command execution failed

The error is created after performing the following:

sudo port clean m4
sudo port upgrade m4

The error was first detected by running the following:

sudo port upgrade gnutls

Thus gnutls is also affected.

[FaradayLight (Faraday Light)]

config.log

[FaradayLight (Faraday Light)]

main.log

[FaradayLight (Faraday Light)]

From the config.log:

configure:6336: checking whether the compiler is clang
configure:6358: /usr/bin/clang -c -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch arm64 -arch x86_64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk conftest.c >&5                                                                                                                                                                                              
conftest.c:13:12: error: unknown type name 'barfbarf'

[leavenode]

1.4.19 just failed to build on Tiger. 1.4.18 is working fine. gnutls upgraded and installed just fine.

From the build log for 1.4.19

:info:build make[3]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/lib'
:info:build depbase=`echo sigsegv.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
:info:build /opt/local/bin/gcc-apple-4.2 -std=gnu99  -I.   -I/opt/local/include  -pipe -Os -arch ppc -MT sigsegv.o -MD -MP -MF $depbase.Tpo -c -o sigsegv.o sigsegv.c &&\
:info:build mv -f $depbase.Tpo $depbase.Po
:info:build sigsegv.c: In function 'sigsegv_handler':
:info:build sigsegv.c:938: error: 'struct mcontext' has no member named '__ss'
:info:build make[3]: *** [sigsegv.o] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/lib'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/lib'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19" && /usr/bin/make -j1 -w all 
:info:build Exit code: 2
:error:build Failed to build m4: command execution failed
:debug:build Error code: CHILDSTATUS 9996 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/main.log for details.

[kencu (Ken)]

the Tiger thing is different -- I think I know what will fix that.

[jmroot (Joshua Root)]

Are your Command Line Tools perhaps outdated? See wiki:ProblemHotlist#reinstall-clt

[FaradayLight (Faraday Light)]

Hi, No I checked that the tools where up today and ran the upgrade after a 'clean' to make sure, but I still got the reported error.

I have also since run 'port diagnose' but that has returned a blank.

This is the version number I get from running the check on the CLT receipt: 12.5.0.0.1.1617976050

[FaradayLight (Faraday Light)]

Having said that, I have just run the pkgutil check without the filter and get the following:

tacitus@malory templates_dev % pkgutil --pkg-info=com.apple.pkg.CLTools_Executables --pkg-info=com.apple.pkg.CLTools_Base --pkg-info=com.apple.pkg.DeveloperToolsCLI --pkg-info=com.apple.pkg.DeveloperToolsCLILeo
package-id: com.apple.pkg.CLTools_Executables
version: 12.5.0.0.1.1617976050
volume: /
location: /
install-time: 1622292831
groups: com.apple.FindSystemFiles.pkg-group 

No receipt for 'com.apple.pkg.CLTools_Base' found at '/'.

No receipt for 'com.apple.pkg.DeveloperToolsCLI' found at '/'.

No receipt for 'com.apple.pkg.DeveloperToolsCLILeo' found at '/'.

I have been installing Xcode updates via App Store.

From - pkgutil --pkgs | grep CL - I get this list:

com.apple.pkg.CLTools_Executables
com.apple.pkg.CLTools_SDK_macOS110
com.apple.pkg.CLTools_SDK_macOS1015
com.apple.pkg.CLTools_macOS_SDK

[FaradayLight (Faraday Light)]

Using the -v switch on another upgrade attempt I get these entries:

checking whether POSIX threads API is available... yes
checking whether setlocale (LC_ALL, NULL) is multithread-safe... no
checking whether setlocale (category, NULL) is multithread-safe... yes
checking whether imported symbols can be declared weak... no
checking host CPU and C ABI... grep: conftest.s: No such file or directory
arm

checking whether C symbols are prefixed with underscore at the linker level... ggrep: conftest.s: No such file or directory
no

checking whether iswblank is declared... no
checking whether iswdigit is ISO C compliant... no
checking whether iswxdigit is ISO C compliant... ./configure: line 38230: test: !=: unary operator expected
./configure: line 38230: test: !=: unary operator expected
guessing yes

checking whether malloc (0) returns nonnull... (cached) no
checking whether mbrtowc handles incomplete characters... ./configure: line 39070: test: !=: unary operator expected
./configure: line 39108: test: !=: unary operator expected
guessing yes
checking whether mbrtowc works as well as mbtowc... guessing yes
checking whether mbrtowc handles a NULL pwc argument... ./configure: line 39267: test: !=: unary operator expected
guessing yes
checking whether mbrtowc handles a NULL string argument... ./configure: line 39340: test: !=: unary operator expected
guessing yes
checking whether mbrtowc has a correct return value... ./configure: line 39403: test: !=: unary operator expected
./configure: line 39403: test: !=: unary operator expected
guessing yes
checking whether mbrtowc returns 0 when parsing a NUL character... guessing yes
checking whether mbrtowc stores incomplete characters... ./configure: line 39662: test: !=: unary operator expected
guessing no

checking whether sleep is declared... no
checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19" && ./configure --prefix=/opt/local --disable-dependency-tracking --disable-silent-rules --program-prefix=g --with-packager=MacPorts --with-packager-version="revision 1" --with-packager-bug-reports=https://trac.macports.org/wiki/Tickets ac_cv_libsigsegv=no 
Exit code: 1

[kencu (Ken)]

Replying to kencu:

the Tiger thing is different -- I think I know what will fix that.

Off topic but I have Tiger fixed so we can forget about that comment here.

[FaradayLight (Faraday Light)]

There is another machine I have access to:

MacBook Pro 16inch, 2019

macOS 11.4

Xcode 12.5

macOS SDK 20.4

M4 upgraded to 1.4.19 without issue on this machine.

[ryanmcgrath (Ryan McGrath)]

I experience the same configure errors on a 2020 M1 MBP - macOS 11.4, Xcode 12.5, reinstalled command line tools recently as well.

The inability to install this +universal is a bit of a sticking point as it blocks a number of other packages. I spent some time looking into it but unfortunately have no real clue what's up - it builds and runs fine if I grab the source and jump through the steps myself, though.

[ryanmcgrath (Ryan McGrath)]

Extra debugging logs, if it helps.

[larryv (Lawrence Velázquez)]

Sorry for the trouble, but I have access to neither Big Sur nor an Apple Silicon machine. Do you experience the same issue non-universally (e.g., sudo port clean m4 && sudo port configure m4)?

Replying to ryanmcgrath:

The inability to install this +universal is a bit of a sticking point as it blocks a number of other packages.

What other ports require m4, a port that installs no libraries, to be universal?

[FaradayLight (Faraday Light)]

I am not familiar with the MacPorts platform or tooling so I have been doing a bit reading-up for the weekend. I am also not familiar the the recent changes to m4/autoconf or the macOS Command Line Tools SDK so I could not be definite about it, but descriptions of similar problems elsewhere and a trawl of the logs suggest it it is not M4 itself.

My thinking at the moment is to attempt to remove MacPorts and re-install it and the ports from scratch to see if perhaps something is just out of kilter.

[ryanmcgrath (Ryan McGrath)]

Replying to larryv:

Sorry for the trouble, but I have access to neither Big Sur nor an Apple Silicon machine. Do you experience the same issue non-universally (e.g., sudo port clean m4 && sudo port configure m4)?

Replying to ryanmcgrath:

The inability to install this +universal is a bit of a sticking point as it blocks a number of other packages.

What other ports require m4, a port that installs no libraries, to be universal?

I can circle back and confirm this, but I was running into this with installing the universal build of curl.

Installing non-universal does work, notably.

[kencu (Ken)]

"+universal" will get passed to m4 if you try to install something else "+universal" that needs m4.

In that case, "+universal" gets passed up the chain to all the build and lib deps.

It's a difficult-to-anticipate hiccup of the way variants work in macports.

All you can do is install the build-tool-deps first (cmake, m4, etc, etc) and then try to install your port +universal. Usually that will sort things out.

[kencu (Ken)]

We could change base to look for "installs_libs no" in a Portfile and if so, ignore "+universal" if it is noted to be passed up from some other build request....

how to do that exactly I have no idea.

"Patches Welcome" :>

[kencu (Ken)]

A similar issue can occur with +java and +debug and +docs and similar variants that you often might mean to have apply only to the port you are installing, but it brings those variants in on any dep with that variant as well.

No doubt one can quickly come up with an opposite case where not having this behaviour breaks everything.

[tomio-arisaka (Tomio Arisaka)]

I made a patch for M1 Mac.

$ diff -u Portfile.orig Portfile
--- Portfile.orig	2021-05-30 04:56:03.000000000 +0900
+++ Portfile	2021-06-05 02:37:51.000000000 +0900
@@ -1,5 +1,6 @@
 PortSystem		1.0
 PortGroup		clang_dependency 1.0
+PortGroup               muniversal 1.0
 
 name            m4
 version         1.4.19
@@ -33,6 +34,13 @@
     patchfiles-append      patch-m4-use-older-regnames-on-tiger.diff
 }
 
+platform arm {
+    set merger_configure_args(arm64)   --host=aarch64-apple-darwin
+    set merger_configure_args(x86_64)  --host=x86_64-apple-darwin
+    set merger_configure_env(arm64)    CC_FOR_BUILD=${configure.cc}
+    set merger_configure_env(x86_64)   CC_FOR_BUILD=${configure.cc}
+}
+
 configure.args  --disable-silent-rules \
                 --program-prefix=g \
                 --with-packager=MacPorts \

It works well for me.

MacBook-Pro:~ $ port installed m4
The following ports are currently installed:
  m4 @1.4.19_1
  m4 @1.4.19_1+universal (active)
MacBook-Pro:~ $ 
MacBook-Pro:~ $ file `which m4`
/usr/bin/m4: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/m4 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/m4 (for architecture arm64e):	Mach-O 64-bit executable arm64e
MacBook-Pro:~ $ 

[FaradayLight (Faraday Light)]

Replying to tomio-arisaka:

I made a patch for M1 Mac.

$ diff -u Portfile.orig Portfile
--- Portfile.orig	2021-05-30 04:56:03.000000000 +0900
+++ Portfile	2021-06-05 02:37:51.000000000 +0900
@@ -1,5 +1,6 @@
 PortSystem		1.0
 PortGroup		clang_dependency 1.0
+PortGroup               muniversal 1.0
 
 name            m4
 version         1.4.19
@@ -33,6 +34,13 @@
     patchfiles-append      patch-m4-use-older-regnames-on-tiger.diff
 }
 
+platform arm {
+    set merger_configure_args(arm64)   --host=aarch64-apple-darwin
+    set merger_configure_args(x86_64)  --host=x86_64-apple-darwin
+    set merger_configure_env(arm64)    CC_FOR_BUILD=${configure.cc}
+    set merger_configure_env(x86_64)   CC_FOR_BUILD=${configure.cc}
+}
+
 configure.args  --disable-silent-rules \
                 --program-prefix=g \
                 --with-packager=MacPorts \

It works well for me.

MacBook-Pro:~ $ port installed m4
The following ports are currently installed:
  m4 @1.4.19_1
  m4 @1.4.19_1+universal (active)
MacBook-Pro:~ $ 
MacBook-Pro:~ $ file `which m4`
/usr/bin/m4: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/m4 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/m4 (for architecture arm64e):	Mach-O 64-bit executable arm64e
MacBook-Pro:~ $ 

Hi,

I am not familiar with the process so I may have gotten this wrong somewhere.

I applied above patch after manually stepping through the fetch, checksum, extract, patch steps. The package configured successfully, and proceeded without error through the manual steps of build and destroot, but it failed in test with:

:info:test Checking ./236.improved_f                                                                                                                                                                              
:info:test Checking ./stackovf.test
:info:test Stack soft limit set to 300K
:info:test Pass
:info:test Skipped checks were:
:info:test   ./125.changeword ./126.changeword ./127.changeword ./128.changeword ./129.changeword ./130.changeword
:info:test Failed checks were:
:info:test   ./198.sysval:err
:info:test make[3]: *** [check-local] Error 1
:info:test make[2]: *** [check-am] Error 2
:info:test make[1]: *** [check-recursive] Error 1
:info:test make: *** [check] Error 2
:info:test Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19-arm64" && /usr/bin/make check 
:info:test Exit code: 2
:error:test Failed to test m4: command execution failed
:debug:test Error code: NONE
:debug:test Backtrace: command execution failed
:debug:test     while executing
:debug:test "$procedure $targetname"
:error:test See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/main.log for details.

related to the above:

:info:test Checking ./197.sysval                                                                                                                                                                                  
:info:test Checking ./198.sysval
:info:test @ ../doc/m4.texi:6751: Origin of test
:info:test ./198.sysval: stderr mismatch
:info:test --- m4-tmp.66915/m4-xerr 2021-06-05 21:00:59.000000000 +0100
:info:test +++ m4-tmp.66915/m4-err  2021-06-05 21:00:59.000000000 +0100
:info:test @@ -0,0 +1 @@
:info:test +sh: line 1: 68899 Killed: 9               /bin/sh -c 'kill -9 $$'
:info:test Checking ./199.mkstemp

Please see attached main_test.log

[FaradayLight (Faraday Light)]

M4 still fails the test phase after removal of all ports followed by a reinstall (with the manual patching and installing of M4 as detailed above).

[larryv (Lawrence Velázquez)]

:info:test Checking ./198.sysval
:info:test @ ../doc/m4.texi:6751: Origin of test
:info:test ./198.sysval: stderr mismatch
:info:test --- m4-tmp.66915/m4-xerr	2021-06-05 21:00:59.000000000 +0100
:info:test +++ m4-tmp.66915/m4-err	2021-06-05 21:00:59.000000000 +0100
:info:test @@ -0,0 +1 @@
:info:test +sh: line 1: 68899 Killed: 9               /bin/sh -c 'kill -9 $$'

:info:test Failed checks were:
:info:test   ./198.sysval:err
:info:test make[3]: *** [check-local] Error 1

This is a bug in the test suite. It will be fixed in the next release.

• ​https://lists.gnu.org/archive/html/bug-m4/2021-06/msg00009.html
• ​https://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=cd7f4d1

[FaradayLight (Faraday Light)]

Replying to larryv:

:info:test Checking ./198.sysval
:info:test @ ../doc/m4.texi:6751: Origin of test
:info:test ./198.sysval: stderr mismatch
:info:test --- m4-tmp.66915/m4-xerr	2021-06-05 21:00:59.000000000 +0100
:info:test +++ m4-tmp.66915/m4-err	2021-06-05 21:00:59.000000000 +0100
:info:test @@ -0,0 +1 @@
:info:test +sh: line 1: 68899 Killed: 9               /bin/sh -c 'kill -9 $$'

:info:test Failed checks were:
:info:test   ./198.sysval:err
:info:test make[3]: *** [check-local] Error 1

This is a bug in the test suite. It will be fixed in the next release.

• ​https://lists.gnu.org/archive/html/bug-m4/2021-06/msg00009.html
• ​https://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=cd7f4d1

Excellent.

Many thanks.

[FaradayLight (Faraday Light)]

Replying to larryv:

Sorry for the trouble, but I have access to neither Big Sur nor an Apple Silicon machine. Do you experience the same issue non-universally (e.g., sudo port clean m4 && sudo port configure m4)?

Replying to ryanmcgrath:

The inability to install this +universal is a bit of a sticking point as it blocks a number of other packages.

What other ports require m4, a port that installs no libraries, to be universal?

Hi, I tested the speck command sequence you suggest, but the package fails to complete the configure phase:

% sudo port clean m4 && sudo port configure m4
Password:
--->  Cleaning m4
--->  Computing dependencies for m4
--->  Fetching distfiles for m4
--->  Verifying checksums for m4
--->  Extracting m4
--->  Configuring m4
Error: Failed to configure m4: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/work/m4-1.4.19/config.log
Error: Failed to configure m4: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_m4/m4/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port m4 failed

The patch provided by tomio-arisaka above resolves the immediate installation problem.

Would you be willing to accept and apply tomio-arisaka's patch to the Portfile to resolve this ticket?

[kencu (Ken)]

Faraday, remove +universal from your variants.conf (and the reinstall all your ports, which will download buildbot versions). Then you will hane no, or at least much less, trouble.

[FaradayLight (Faraday Light)]

Hi, I have commented out the setting in variants and that has resolved the issues I have been experiencing.

[ryanmcgrath (Ryan McGrath)]

I wound up just shoving the patched m4 in as a Portfile in my local ports setup, which does work for me as well.

[FaradayLight (Faraday Light)]

Replying to ryanmcgrath:

I wound up just shoving the patched m4 in as a Portfile in my local ports setup, which does work for me as well.

Hi, M4 built without the patch on arm64 after commenting-out the +unversal option in the resources.conf; could you check if the setting has been applied in your resources.conf as well?

[ryandesign (Ryan Carsten Schmidt)]

The actual error in the log is:

:info:configure checking for socklen_t... no
:info:configure checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t

I feel like we've seen this with tons of other ports. Check other tickets.

Replying to FaradayLight:

Hi, M4 built without the patch on arm64 after commenting-out the +unversal option in the resources.conf; could you check if the setting has been applied in your resources.conf as well?

variants.conf.

[kencu (Ken)]

Most likely running the universal build using the muninversal PG as per 62991#comment:19 is going to be the fix here.

[ShadSterling (Shad Sterling)]

Just ran in to this error trying to upgrade diffutils @3.7_0+universal (active). I don't think it has been reported on tons of other ports, this was the only result in my search for socklen_t that was less than 3 years old. Is this the same problem affecting multiple ports that should all be collected in this ticket, or should I open a separate ticket for diffutils?

[kencu (Ken)]

Replying to ShadSterling:

Just ran in to this error trying to upgrade diffutils @3.7_0+universal (active). I don't think it has been reported on tons of other ports, this was the only result in my search for socklen_t that was less than 3 years old. Is this the same problem affecting multiple ports that should all be collected in this ticket, or should I open a separate ticket for diffutils?

no need to open up another ticket for diffutils. Anything that triggers a build of m4 +universal will cause this.

Until someone spends the time to sort out a proper universal build for m4 that works on all os versions, the simple workaround is to just install m4 first:

sudo port install m4

and then install the port you want, eg diffutils:

sudo port -v install diffutils +universal

and it should work just fine.

[raw-bin (Robin Randhawa)]

I think it's the same problem so might be better to use this ticket.

I should point out that in my case (Big Sur 11.5.1 on an M1 Silicon based Macbook Pro 13) with macports HEAD, just:

sudo port install m4

.. fails with the socklen_t complaint so I cannot progress to the next step.

[raw-bin (Robin Randhawa)]

Please ignore my last comment. Apparently I did not clean out a previously failing m4 build.

[kencu (Ken)]

The issue here is that we can't configure both arm64 and intel in one pass using dual archs at present, so we'll need to use the muniversal PG to get through the configure stage.

configure:57981: checking for socklen_t
configure:57981: /usr/bin/clang -c -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch arm64 -arch x86_64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk conftest.c >&5
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:81:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/machine/endian.h:35:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/i386/endian.h:99:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_endian.h:130:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/_OSByteOrder.h:80:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/arm/OSByteOrder.h:8:
In file included from /Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/include/stdint.h:52:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/stdint.h:58:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/_types/_intmax_t.h:32:25: error: cannot combine with previous 'long long' declaration specifier
typedef __INTMAX_TYPE__ intmax_t;
                        ^
conftest.c:204:23: note: expanded from macro 'intmax_t'
#define intmax_t long long
                      ^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:81:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/machine/endian.h:35:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/i386/endian.h:99:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_endian.h:130:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/_OSByteOrder.h:80:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/arm/OSByteOrder.h:15:1: error: redefinition of '_OSSwapInt16'
_OSSwapInt16(
^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/i386/_OSByteOrder.h:46:1: note: previous definition is here
_OSSwapInt16(
^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:81:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/machine/endian.h:35:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/i386/endian.h:99:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_endian.h:130:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/_OSByteOrder.h:80:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/arm/OSByteOrder.h:25:1: error: redefinition of '_OSSwapInt32'
_OSSwapInt32(
^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/i386/_OSByteOrder.h:55:1: note: previous definition is here
_OSSwapInt32(
^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:81:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/machine/endian.h:35:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/i386/endian.h:99:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_endian.h:130:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/_OSByteOrder.h:80:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/arm/OSByteOrder.h:41:1: error: redefinition of '_OSSwapInt64'
_OSSwapInt64(
^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/libkern/i386/_OSByteOrder.h:70:1: note: previous definition is here
_OSSwapInt64(
^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:123:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_types/_off_t.h:31:33: error: cannot combine with previous 'type-name' declaration specifier
typedef __darwin_off_t          off_t;
                                ^
conftest.c:216:20: note: expanded from macro 'off_t'
#define off_t long int
                   ^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:123:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_types/_off_t.h:31:33: error: 'long type-name' is invalid
conftest.c:216:15: note: expanded from macro 'off_t'
#define off_t long int
              ^
In file included from conftest.c:526:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/types.h:167:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/sys/_types/_ssize_t.h:31:33: error: cannot combine with previous 'type-name' declaration specifier
typedef __darwin_ssize_t        ssize_t;
                                ^
conftest.c:414:17: note: expanded from macro 'ssize_t'
#define ssize_t int
                ^
7 errors generated.

[MarkCallow (Mark Callow)]

What other ports require m4, a port that installs no libraries, to be universal?

I am trying

sudo port install assimp +universal

and get the socklen_t unknown type issue. I already have assimp and m4 installed for x86_64. So the advice from @kencu:

Until someone spends the time to sort out a proper universal build for m4 that works on all os versions, the simple workaround is to just install m4 first:

does not work.

Ultimately I used tomio-arisaka's muniversal PG patch to get past the problem. Big thanks @tomio-arisaka but when you, or anyone, post such patches please have a thought for those not intimately familiar with MacPorts and give the full path of the file being patched. For anyone else coming along, it is

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/m4

[kencu (Ken)]

I just tried again, Mark, and once m4 is installed, it does not require being rebuilt as +universal:

% sudo port -v installed | grep active
  autoconf @2.71_1 (active) requested_variants='' platform='darwin 20' archs='noarch' date='2021-08-21T14:56:06-0400'
  automake @1.16.3_0 (active) requested_variants='' platform='darwin 20' archs='noarch' date='2021-08-21T14:56:12-0400'
  bzip2 @1.0.8_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:00:53-0400'
  curl-ca-bundle @7.78.0_0 (active) requested_variants='' platform='darwin 20' archs='noarch' date='2021-08-21T15:22:19-0400'
  db48 @4.8.30_4+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:10:45-0400'
  expat @2.4.1_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:20:17-0400'
  gdbm @1.20_1+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:11:16-0400'
  gettext @0.19.8.1_2+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:06:53-0400'
  gperf @3.1_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:00:57-0400'
  help2man @1.48.4_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:15:16-0400'
  libedit @20210216-3.1_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:20:32-0400'
  libiconv @1.16_1+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:01:36-0400'
  libidn2 @2.3.2_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:20:03-0400'
  libtool @2.4.6_11+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:08:49-0400'
  libunistring @0.9.10_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:19:00-0400'
  m4 @1.4.19_1 (active) requested_variants='' platform='darwin 20' archs='arm64' date='2021-08-21T14:55:48-0400'
  ncurses @6.2_1+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:02:15-0400'
  p5.30-locale-gettext @1.70.0_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:15:14-0400'
  perl5.30 @5.30.3_3+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:15:08-0400'
  pkgconfig @0.29.2_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:19:42-0400'
  readline @8.1.000_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:11:06-0400'
  texinfo @6.8_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:16:08-0400'
  xz @5.2.5_0+universal (active) requested_variants='+universal' platform='darwin 20' archs='arm64 x86_64' date='2021-08-30T01:11:30-0400'

So I don't know why it didn't work for you, but at least on an M1 mac, what I said appears perfectly valid.

My best guess is that you didn't clean m4 before trying to rebuild it, but that is speculation.

now, assimp won't build universal for me because libffi won't build universal at present on an M1 system 62449 but that is a separate issue.

[MarkCallow (Mark Callow)]

Installation of m4 without +universal succeeded so it never occurred to me that clean might be necessary. What I did next was

sudo port install openimageio +universal

The first thing port tried to do after that was install m4+universal, That installation attempt is not something I had control over. That is what failed with the socklen_t unknown type issue. I very much doubt that clean would have helped.

I'm on an Intel MacBook. libffi+universal installation succeeded for me.

[kencu (Ken)]

Well of course cleaning would have helped.

sudo port install m4

works fine on every macOS system. I fixed it on the ones where it did not work.

once m4 it is installed, macports will not ask for m4 to be rebuilt as +universal unless you do something unusual to force it to do that (because it doesn't install any libs).

So what I said works fine, and it is the easiest solution.

Now, if I get time, or somebody else gets interested, we can see if m4 will properly build +universal using the patch above or some other fix. We'd like it to build +universal. Somebody has to properly patch it to do so, then check that it all works properly.

But a perfectly simple solution is to install it first without universal. I realize you are new to MacPorts, and didn't know to clean m4 between build attempts.

But telling everyone that "kencu's solution didn't work" when you most likely didn't do it correctly is not exactly correct either.

[MarkCallow (Mark Callow)]

Replying to kencu:

Well of course cleaning would have helped.

sudo port install m4

works fine on every macOS system. I fixed it on the ones where it did not work.

I did do that and it worked. Quoting myself "Installation of m4 without +universal succeeded". In other words I did the command you've quoted above and it worked. So I don't understand where I am supposed to have run clean.

once m4 it is installed, macports will not ask for m4 to be rebuilt as +universal unless you do something unusual to force it to do that (because it doesn't install any libs).

So are you telling me that

sudo port install openimageio +universal

is unusual? As I wrote, that is all I did and port took it upon itself to attempt to install m4 +universal.

Now, if I get time, or somebody else gets interested, we can see if m4 will properly build +universal using the patch above or some other fix. We'd like it to build +universal. Somebody has to properly patch it to do so, then check that it all works properly.

The patch worked for me.

[kencu (Ken)]

If you did:

sudo port install m4

and then it installed, and then you did

sudo port install openimageio +universal

and macports insisted on trying to reinstall m4 +universal and would not use the installed m4 that was already there, then that would be a variance from what is expected and from what I see indeed.

I can't reproduce that at present, but if that is what you saw, then that is what you saw.

I'll try on an Intel BigSur system and see if it behaves differently than an M1 BigSur system, which would be unexpected but nothing is impossible in this world I guess.

[kencu (Ken)]

In 90f54b62b5acd0e1505c83dd36acf628bef7c979/macports-ports (master):

m4: fix universal build

requires muniversal PortGroup when building cross-architecture
closes: #62991

[kencu (Ken)]

I found only the muniversal PG was needed. No other modifications were required.