brew install error on macOS 14.4.1

[rainsoft]

❯ brew install nativeos/i386-elf-toolchain/i386-elf-gcc ==> Fetching nativeos/i386-elf-toolchain/i386-elf-gcc ==> Downloading https://ftp.gnu.org/gnu/gcc/gcc-12.2.0/gcc-12.2.0.tar.xz Already downloaded: /Users/Rain/Library/Caches/Homebrew/downloads/9caf98c99bc119654de91583a325f293ed9186c1cc664ca548b1a3554d948cb9--gcc-12.2.0.tar.xz ==> Installing i386-elf-gcc from nativeos/i386-elf-toolchain ==> ../configure --prefix=/opt/homebrew/Cellar/i386-elf-gcc/12.2.0_2 --target=i386-elf --disable-multilib --disable-nls --disable-werror --without-hea ==> make all-gcc Last 15 lines from /Users/Rain/Library/Logs/Homebrew/i386-elf-gcc/02.make: In file included from ../../gcc/system.h:233: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/vector:321: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/format/formatter_bool.h:20: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/locale:202: /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/c++/v1/locale:813:5: error: expected expression return std::use_facet<ctype<_CharT> >(__loc).is(ctype_base::cntrl, __c); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make[1]: [cp/mapper-resolver.o] Error 1 20 errors generated. make[1]: [cp/module.o] Error 1 rm gcc.pod make: *** [all-gcc] Error 2

[Non808]

I also have this error, exactly the same logs.

[coolcoder613eb]

Me too.

[danirod]

Sorry for the delay (to be honest, I just switched to clang for my own i386-elf purposes, but I still like to update this repo if I'm able to).

I've updated the GCC version carried by this tap to GCC 14.1, and it seems to compile OK on my M2 system with macOS 14.4.1.

If someone can replicate that this i386-elf-gcc is working now, I'll mark the issue as fixed.

[coolcoder613eb]

> brew install nativeos/i386-elf-toolchain/i386-elf-gcc
==> Fetching nativeos/i386-elf-toolchain/i386-elf-gcc
==> Downloading https://ftp.gnu.org/gnu/gcc/gcc-14.1.0/gcc-14.1.0.tar.xz
Already downloaded: /Users/coolcoder613/Library/Caches/Homebrew/downloads/0e325bfa711700e4152495183837a37687c403f52a9a1251b668ca0d890ac7e3--gcc-14.1.0.tar.xz
==> Installing i386-elf-gcc from nativeos/i386-elf-toolchain
==> ../configure --prefix=/opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1 --target=i
==> make all-gcc
==> make install-gcc
==> make all-target-libgcc
Last 15 lines from /Users/coolcoder613/Library/Logs/Homebrew/i386-elf-gcc/04.make:
checking host system type... i386-pc-elf
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... awk
checking for i386-elf-ar... i386-elf-ar
checking for i386-elf-lipo... i386-elf-lipo
checking for i386-elf-nm... /private/tmp/i386-elf-gcc-20240530-34652-s50lfi/gcc-14.1.0/gcc-build/./gcc/nm
checking for i386-elf-ranlib... i386-elf-ranlib
checking for i386-elf-strip... i386-elf-strip
checking whether ln -s works... yes
checking for i386-elf-gcc...  /private/tmp/i386-elf-gcc-20240530-34652-s50lfi/gcc-14.1.0/gcc-build/./gcc/xgcc -B/private/tmp/i386-elf-gcc-20240530-34652-s50lfi/gcc-14.1.0/gcc-build/./gcc/ -B/opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1/i386-elf/bin/ -B/opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1/i386-elf/lib/ -isystem /opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1/i386-elf/include -isystem /opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1/i386-elf/sys-include
checking for suffix of object files... configure: error: in `/private/tmp/i386-elf-gcc-20240530-34652-s50lfi/gcc-14.1.0/gcc-build/i386-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
make: *** [configure-target-libgcc] Error 1

If reporting this issue please do so at (not Homebrew/brew or Homebrew/homebrew-core):
  https://github.com/nativeos/homebrew-i386-elf-toolchain/issues

[danirod]

😅 Okay, let me check

[danirod]

I've bumped the version of GNU binutils that this tap is carrying to 2.42. I haven't checked the compatibility table, but it totally could be that Binutils 2.37 cannot be used with GCC 14.1.

I'm testing on a separate and empty Homebrew installation and it seems to work.

[coolcoder613eb]

For grub:

brew install nativeos/i386-elf-toolchain/i386-elf-grub
==> Auto-updating Homebrew...
Adjust how often this is run with HOMEBREW_AUTO_UPDATE_SECS or disable with
HOMEBREW_NO_AUTO_UPDATE. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Fetching nativeos/i386-elf-toolchain/i386-elf-grub
==> Downloading https://ftp.gnu.org/gnu/grub/grub-2.06.tar.xz
Already downloaded: /Users/coolcoder613/Library/Caches/Homebrew/downloads/0c1713947d455e47ae633568d4fea9d3fbff2a9e9353c69948106ee1cba57286--grub-2.06.tar.xz
==> Installing i386-elf-grub from nativeos/i386-elf-toolchain
==> ../configure --disable-nls --disable-werror --disable-efiemu --target=i386-elf --prefix=/opt/homebrew/Cellar/i386-elf-grub/2.06_1 TARGET_CC=i386-elf-gcc TARGET_NM=i386-el
==> make install

...

i386-elf-gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W  -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -m32 -nostdinc -isystem /opt/homebrew/Cellar/i386-elf-gcc/14.1.0_1/lib/gcc/i386-elf/14.1.0/include -I../../include -I../include -DGRUB_FILE=\"disk/ldm.c\" -I. -I../../grub-core -I.. -I../.. -I../../include -I../include -I../../grub-core/lib/libgcrypt-grub/src/    -D_FILE_OFFSET_BITS=64 -std=gnu99 -Os -m32 -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations  -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -march=i386 -mrtd -mregparm=3 -falign-jumps=1 -falign-loops=1 -falign-functions=1 -freg-struct-return -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -msoft-float -fno-dwarf2-cfi-asm -mno-stack-arg-probe -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-ident -fno-stack-protector -Wtrampolines   -ffreestanding   -MT disk/ldm_module-ldm.o -MD -MP -MF disk/.deps-core/ldm_module-ldm.Tpo -c -o disk/ldm_module-ldm.o `test -f 'disk/ldm.c' || echo '../../grub-core/'`disk/ldm.c
In file included from ../../grub-core/disk/luks2.c:30:
../../grub-core/disk/luks2.c: In function 'luks2_verify_key':
../../grub-core/disk/luks2.c:397:75: error: passing argument 5 of 'base64_decode_ctx' from incompatible pointer type [-Wincompatible-pointer-types]
  397 |   if (!base64_decode (d->digest, grub_strlen (d->digest), (char *)digest, &digestlen))
      |                                                                           ^~~~~~~~~~
      |                                                                           |
      |                                                                           grub_size_t * {aka unsigned int *}
../../grub-core/lib/gnulib/base64.h:65:50: note: in definition of macro 'base64_decode'
   65 |         base64_decode_ctx (NULL, in, inlen, out, outlen)
      |                                                  ^~~~~~
../../grub-core/lib/gnulib/base64.h:58:60: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'grub_size_t *' {aka 'unsigned int *'}
   58 |                                char *restrict out, size_t *outlen);
      |                                                    ~~~~~~~~^~~~~~
../../grub-core/disk/luks2.c:399:69: error: passing argument 5 of 'base64_decode_ctx' from incompatible pointer type [-Wincompatible-pointer-types]
  399 |   if (!base64_decode (d->salt, grub_strlen (d->salt), (char *)salt, &saltlen))
      |                                                                     ^~~~~~~~
      |                                                                     |
      |                                                                     grub_size_t * {aka unsigned int *}
../../grub-core/lib/gnulib/base64.h:65:50: note: in definition of macro 'base64_decode'
   65 |         base64_decode_ctx (NULL, in, inlen, out, outlen)
      |                                                  ^~~~~~
../../grub-core/lib/gnulib/base64.h:58:60: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'grub_size_t *' {aka 'unsigned int *'}
   58 |                                char *restrict out, size_t *outlen);
      |                                                    ~~~~~~~~^~~~~~
../../grub-core/disk/luks2.c: In function 'luks2_decrypt_key':
../../grub-core/disk/luks2.c:438:36: error: passing argument 5 of 'base64_decode_ctx' from incompatible pointer type [-Wincompatible-pointer-types]
  438 |                      (char *)salt, &saltlen))
      |                                    ^~~~~~~~
      |                                    |
      |                                    grub_size_t * {aka unsigned int *}
../../grub-core/lib/gnulib/base64.h:65:50: note: in definition of macro 'base64_decode'
   65 |         base64_decode_ctx (NULL, in, inlen, out, outlen)
      |                                                  ^~~~~~
../../grub-core/lib/gnulib/base64.h:58:60: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'grub_size_t *' {aka 'unsigned int *'}
   58 |                                char *restrict out, size_t *outlen);
      |                                                    ~~~~~~~~^~~~~~
make[3]: *** [disk/luks2_module-luks2.o] Error 1
make[3]: *** Waiting for unfinished jobs....
mv -f disk/.deps-core/afsplitter_module-AFSplitter.Tpo disk/.deps-core/afsplitter_module-AFSplitter.Po
mv -f commands/.deps-core/test_module-test.Tpo commands/.deps-core/test_module-test.Po
mv -f disk/.deps-core/luks_module-luks.Tpo disk/.deps-core/luks_module-luks.Po
mv -f disk/.deps-core/geli_module-geli.Tpo disk/.deps-core/geli_module-geli.Po
mv -f lib/gnulib/.deps-core/luks2_module-base64.Tpo lib/gnulib/.deps-core/luks2_module-base64.Po
mv -f disk/.deps-core/ldm_module-ldm.Tpo disk/.deps-core/ldm_module-ldm.Po
mv -f disk/.deps-core/lvm_module-lvm.Tpo disk/.deps-core/lvm_module-lvm.Po
make[2]: *** [install] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2

[AndrewAPrice]

I can't build i386-elf-grub on a 64-bit machine. I get:

../../grub-core/lib/gnulib/base64.h:58:60: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'grub_size_t *' {aka 'unsigned int *'}
   58 |                                char *restrict out, size_t *outlen);
      |                                                    ~~~~~~~~^~~~~~

[danirod]

Yeah, I am still looking at it. I believe that some packages just aren't compatible with macOS 14's clang yet, I can't build neither gdb nor grub with macOS 14's default compiler. Something something make[3]: *** No rule to make target../../grub-core/extra_deps.lst', needed by syminfo.lst'. Stop.

I should probably just make these packages build-depend on normal gcc and binutils, because I'm very, very tired of these quirks whenever macOS releases a software update.

[snacsnoc]

@coolcoder613eb I was able to successfully compile grub 2.06, with the same configure options in this formula.

../configure --disable-nls --disable-werror --disable-efiemu --target=i386-elf --prefix=/opt/homebrew/Cellar/i386-elf-grub/2.06_1 TARGET_CC=i386-elf-gcc TARGET_NM=i386-elf-nm TARGET_OBJCOPY=i386-elf-objcopy TARGET_RANLIB=i386-elf-ranlib TARGET_STRIP=i386-elf-strip && make -j8

To fix the type mismatch, this simple patch I put together, while hacky, does work:

--- grub-core/disk/luks2_original.c 2021-04-12 08:08:22
+++ grub-core/disk/luks2.c  2024-07-05 22:46:52
@@ -394,11 +394,16 @@
   gcry_err_code_t gcry_ret;

   /* Decode both digest and salt */
-  if (!base64_decode (d->digest, grub_strlen (d->digest), (char *)digest, &digestlen))
+  size_t temp_digestlen = digestlen;  // Temporary size_t variable for the decoding function
+  if (!base64_decode(d->digest, grub_strlen(d->digest), (char *)digest, &temp_digestlen))
     return grub_error (GRUB_ERR_BAD_ARGUMENT, "Invalid digest");
-  if (!base64_decode (d->salt, grub_strlen (d->salt), (char *)salt, &saltlen))
+  digestlen = temp_digestlen; 
+  size_t temp_saltlen = saltlen;  // Temporary size_t variable for the decoding function
+  if (!base64_decode(d->salt, grub_strlen(d->salt), (char *)salt, &temp_saltlen))
     return grub_error (GRUB_ERR_BAD_ARGUMENT, "Invalid digest salt");
+  saltlen = temp_saltlen;  

+
   /* Configure the hash used for the digest. */
   hash = grub_crypto_lookup_md_by_name (d->hash);
   if (!hash)
@@ -434,12 +439,14 @@
   gcry_err_code_t gcry_ret;
   grub_err_t ret;

-  if (!base64_decode (k->kdf.salt, grub_strlen (k->kdf.salt),
-           (char *)salt, &saltlen))
-    {
-      ret = grub_error (GRUB_ERR_BAD_ARGUMENT, "Invalid keyslot salt");
-      goto err;
-    }
+  size_t temp_saltlen = saltlen;  // Temporary size_t variable for the correct type
+  if (!base64_decode(k->kdf.salt, grub_strlen(k->kdf.salt), (char *)salt, &temp_saltlen))
+  {
+    ret = grub_error(GRUB_ERR_BAD_ARGUMENT, "Invalid keyslot salt");
+    goto err;
+  }
+  saltlen = temp_saltlen;  
+

   /* Calculate the binary area key of the user supplied passphrase. */
   switch (k->kdf.type)

The patch resolves type mismatch errors by adding temporary size_t variables (temp_digestlen and temp_saltlen) for the output sizes in base64_decode calls, replacing the incorrect grub_size_t* parameters. This seems to stem from a cross-compiling issue in of itself, a more holistic solution to fix the mismatched types should be created.