libiconv installed from ??? does not include arm64 so breaks macOS Ventura installation.

[josmithiii]

As a result of this, gettext-runtime installation fails, which is how I discovered it. Here is documentation of the ARMless installation of libiconv in an ARM environment:

> lipo -info /usr/local/lib/libiconv.2.4.0.dylib
Architectures in the fat file: /usr/local/lib/libiconv.2.4.0.dylib are: i386 ppc 
> uname -a
Darwin mp14 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64
> port -v
MacPorts 2.8.0
> port installed | grep libiconv
  libiconv @1.17_0 (active)
> port variants libiconv
libiconv has the variants:
   universal: Build for multiple architectures

[kencu (Ken)]

where did you get your libiconv, exactly?

Here's my perfectly good libiconv, on a stock M1 Mac:

% uname -a
Darwin Kens-MBP 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64

% port contents libiconv | grep dylib
  /opt/local/lib/libcharset.1.dylib
  /opt/local/lib/libcharset.dylib
  /opt/local/lib/libiconv.2.dylib
  /opt/local/lib/libiconv.dylib

% file  /opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
/opt/local/lib/libiconv.2.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/lib/libiconv.2.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

[josmithiii]

Thanks for the clue. It's ok now after this (which I also tried earlier to no effect):

sudo port uninstall libiconv
sudo port clean libiconv
sudo port install libiconv

If MacPorts stores a history of downloads, I would be happy to look up where the previous version came from. It must be a bad server that I'm not getting now?

[kencu (Ken)]

very glad you got that sorted out so easily!

[ryandesign (Ryan Carsten Schmidt)]

Replying to josmithiii:

Interestingly, now the only architecture present is arm64, even though the only variant is universal.

The port has a universal variant available but presumably you have not requested the use of that variant. If you had, then it would have been installed with multiple architectures (on Ventura, x86_64 and arm64).

If MacPorts stores a history of downloads, I would be happy to look up where the previous version came from.

It doesn't.

It must be a bad server that I'm not getting now?

The problem you reported was about a file in /usr/local, so it did not come from MacPorts (unless you built MacPorts from source with the configure arguments --prefix=/usr/local --with-unsupported-prefix, which would be unsupported).

If a download you got via MacPorts was corrupted in some way, MacPorts would not attempt to install it. There are digital signatures (for binaries) and checksums (for sources) to prevent such problems.

[josmithiii]

Thanks for the info. Yes, I was unclear on the /usr/local usage. It appears a wrong-architecture instance of a library in /usr/local/lib will satisfy a MacPorts dependency. I had many such libraries created from a Time Machine backup when I moved to an ARM machine. I am now deleting all the libraries not having ARM support based on lipo -info ... .