icu @53.1_1 +universal: icu-config differs and cannot be merged

[nerdling (Jeremy Lavergne)]

The muniversal comparison fails in destroot.

Command failed: /usr/bin/cmp -s "/tmp/muniversal.IIUyfHAa/1-icu-config" "/tmp/muniversal.IIUyfHAa/2-icu-config"
Exit code: 1
Error: Failed to destroot icu: icu-config differs in /opt/pspp/var/macports/build/_opt_pspp_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_icu/icu/work/destroot-powerpc//opt/pspp/bin and /opt/pspp/var/macports/build/_opt_pspp_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_icu/icu/work/destroot-intel//opt/pspp/bin and cannot be merged
DEBUG: Error code: NONE

[nerdling (Jeremy Lavergne)]

The -config files differ regarding endian/architecture:

$ sudo diff -u "/tmp/muniversal.19cP5CrA/1-icu-config" "/tmp/muniversal.19cP5CrA/2-icu-config"
--- /tmp/muniversal.19cP5CrA/1-icu-config	2014-10-06 13:15:17.000000000 -0400
+++ /tmp/muniversal.19cP5CrA/2-icu-config	2014-10-06 13:15:17.000000000 -0400
@@ -187,9 +187,9 @@
 ##################################################################
 
 # Information about the host that 'configure' was run on.
-host="powerpc-apple-darwin9.8.0"
-host_alias="powerpc-apple-darwin9.8.0"
-host_cpu="powerpc"
+host="i386-apple-darwin9.8.0"
+host_alias=""
+host_cpu="i386"
 host_vendor="apple"
 host_os="darwin9.8.0"
 # Our platform canonical name (as determined by configure)
@@ -211,7 +211,7 @@
 CXXFLAGS=""
 CXX="/usr/bin/g++-4.2"
 DEFAULT_MODE="dll"
-DEFS="-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBM=1 -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LIBPTHREAD=1 -DHAVE_INTTYPES_H=1 -DHAVE_DIRENT_H=1 -DWORDS_BIGENDIAN=1 -DHAVE_WCHAR_H=1 -DSIZEOF_WCHAR_T=4 "
+DEFS="-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBM=1 -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LIBPTHREAD=1 -DHAVE_INTTYPES_H=1 -DHAVE_DIRENT_H=1 -DHAVE_WCHAR_H=1 -DSIZEOF_WCHAR_T=4 "
 FFLAGS="@FFLAGS@"
 # use a consistent INSTALL 
 INSTALL="${SHELL} ${pkgdatadir}/install-sh -c"
@@ -229,7 +229,7 @@
 SHELL="/bin/sh"
 SHLIB_c="${CC} ${DEFS} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} -shared"
 SHLIB_cc="${CXX} ${DEFS} ${CPPFLAGS} ${CXXFLAGS} ${LDFLAGS} -shared"
-U_IS_BIG_ENDIAN="1"
+U_IS_BIG_ENDIAN="0"
 includedir="${prefix}/include"
 infodir="${datarootdir}/info"
 localstatedir="${prefix}/var"
@@ -249,8 +249,8 @@
 ##################################################################
 
 # The basename of the ICU data file (i.e. icudt21b )
-ICUDATA_CHAR="b"
-ICUDATA_NAME="icudt53b"
+ICUDATA_CHAR="l"
+ICUDATA_NAME="icudt53l"
 
 # Defaults for pkgdata's mode and directories
 # The default data dir changes depending on what packaging mode 

[potmj (Michael Pot)]

Cc Me!

[Ionic (Mihai Moldovan)]

For some reason I'm hitting the same issue on 10.9.

However, I'm getting a different diff:

--- /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_devel_icu/icu/work/destroot-i386//opt/local/bin/icu-config	2015-05-13 08:51:17.000000000 +0200
+++ /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_devel_icu/icu/work/destroot-x86_64//opt/local/bin/icu-config	2015-05-13 08:51:03.000000000 +0200
@@ -211,7 +211,7 @@
 CXXFLAGS="--std=c++0x"
 CXX="/usr/bin/clang++"
 DEFAULT_MODE="dll"
-DEFS="-DPACKAGE_NAME=\"ICU\" -DPACKAGE_TARNAME=\"International\ Components\ for\ Unicode\" -DPACKAGE_VERSION=\"55.1\" -DPACKAGE_STRING=\"ICU\ 55.1\" -DPACKAGE_BUGREPORT=\"http://icu-project.org/bugs\" -DPACKAGE_URL=\"http://icu-project.org\" -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBM=1 -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LIBPTHREAD=1 -DHAVE_INTTYPES_H=1 -DHAVE_DIRENT_H=1 -DHAVE_WCHAR_H=1 -DSIZEOF_WCHAR_T=4 "
+DEFS="-DPACKAGE_NAME=\"ICU\" -DPACKAGE_TARNAME=\"International\ Components\ for\ Unicode\" -DPACKAGE_VERSION=\"55.1\" -DPACKAGE_STRING=\"ICU\ 55.1\" -DPACKAGE_BUGREPORT=\"http://icu-project.org/bugs\" -DPACKAGE_URL=\"http://icu-project.org\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBM=1 -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LIBPTHREAD=1 -DHAVE_INTTYPES_H=1 -DHAVE_DIRENT_H=1 -DHAVE_WCHAR_H=1 -DSIZEOF_WCHAR_T=4 "
 # use a consistent INSTALL
 INSTALL="${SHELL} ${pkgdatadir}/install-sh -c"
 INSTALL_DATA="${INSTALL} -m 644"

The difference is an added/removed -DSTDC_HEADERS=1 switch.

Can this be classified as the same issue, or is it really a new bug? It's "somewhat equal", but probably different enough to be its own ticket. Not sure though.

icu 54.1 compiled fine previously, but I've since also upgraded my Xcode/CLT toolchain, so this particular issue may be either triggered by 55.1 or the toolchain upgrade. I guess it's probably a new bug in 55.1.

[Ionic (Mihai Moldovan)]

Turns out this was just /usr/bin/clang segfaulting during a *very* bad time -- at x86 configure time while checking for ANSI C headers.

So not a bug in icu, but the toolchain is segfaulting (again) for me.

[ryandesign (Ryan Carsten Schmidt)]

It builds fine for me with the universal variant on Yosemite. So this ticket continues to be about the original problem: that the icu-config script cannot be merged when building universal for architectures of different endianness. I am not working on fixing this problem; it would be up to the developers of icu to modify their build system so that it does not create these differences based on endianness.

[larryv (Lawrence Velázquez)]

Perhaps the port could just disallow Intel+PPC builds?

[ryandesign (Ryan Carsten Schmidt)]

I don't think we have a directive to do that, do we? I would have to write the code to do that. Something like if ${configure.universal_archs} contains "ppc" and it contains "86", then universal_variant no. That's assuming the muniversal portgroup even honors universal_variant no, which it looks like it does not. So then it becomes if ${configure.universal_archs} does not contain "ppc" and "86", then include the muniversal portgroup. Which would mean making sure the port works correctly whether or not the muniversal portgroup is included, which might be complicated, though I don't see anything immediately problematic about that in icu.

[ryandesign (Ryan Carsten Schmidt)]

The problem remains with icu @67.1+universal and also affects arm64/x86_64 builds.

These types of problems have been discussed in ​https://unicode-org.atlassian.net/browse/ICU-20030.

There have been several upstream bug reports over the years asking for icu-config to be removed; see ​https://unicode-org.atlassian.net/browse/ICU-10464. So we could just remove it.

[ryandesign (Ryan Carsten Schmidt)]

Removing icu-config won't fully solve it. The Makefile.inc files also contain the differing host/host_alias/host_cpu section, and MacPorts misidentifies Makefile.inc as a header and merges it as if it were a header, which will make the file wrong. icu-config and the Makefile.inc files are both deprecated, but even the pkg-config .pc files contain the ICUDATA_NAME variable which differs based on endianness. I have now reported that as ​https://unicode-org.atlassian.net/browse/ICU-21382.

[jpanetta (Julian Panetta)]

This seems to be blocking many other ports from installing (e.g.,llvm-9.0, gcc10, OpenBLAS). The non-universal variant of icu installs fine, but then trying to install a non-universal variant of these dependent ports still tries to install a universal build of icu. Is there a way to force all dependencies to be installed with -universal?

Edit: +universal was propagating despite specifying -universal due to a supported_arches omitting arm64 in llvm-9.0, as discussed here: comment:ticket:61636:11

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #61677.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jpanetta:

This seems to be blocking many other ports from installing (e.g.,llvm-9.0, gcc10, OpenBLAS). The non-universal variant of icu installs fine, but then trying to install a non-universal variant of these dependent ports still tries to install a universal build of icu. Is there a way to force all dependencies to be installed with -universal?

Edit: +universal was propagating despite specifying -universal due to a supported_arches omitting arm64 in llvm-9.0, as discussed here: comment:ticket:61636:11

Not building universal is the default. MacPorts will only build a port universal if that is required, for example because a port you wanted to install (or one of its dependencies) does not support the architecture for which you are trying to build. This will be a common problem on Apple Silicon machines as we have many ports that indicate (rightly or wrongly) that they only support Intel Macs. (Many probably indicate this because they don't support PowerPC Macs, not because they don't support Apple Silicon Macs, though many may need further patches to be compatible with Apple Silicon.)

[maralski (Peter Marelas)]

Yeah I am seeing the same icu-config issue with Apple Silicon trying to install KeePassXC.

[GabrielDougherty (Gabriel Dougherty)]

Commenting for the benefit of others new to MacPorts & Apple Silicon looking for a temporary workaround -

I was trying to install nodejs14 and got this icu error. I reinstalled the Rosetta version with the following commands:

sudo port clean icu
sudo port clean nodejs14
sudo arch -arch x86_64 port install nodejs14

[kencu (Ken)]

So this ticket becomes an issue again with a need for arm64/Intel universal builds forthcoming.

It's actually fairly easy to build icu +universal on BigSur:

% port -v installed icu
The following ports are currently installed:
  icu @67.1_2+universal (active) platform='darwin 20' archs='arm64 x86_64' date='2021-01-10T17:29:50-0500'

the quick fix is to copy the arm64 icu-config shell script into the x86_64 icu-config, pre-destroot, like this (manually)

sudo cp ./source-arm64/config/icu-config ./source-x86_64/config/icu-config

and then away you go. The pkg-config files are identical, it seems.

The icu-config files differ only minorly, with respect to the host and host cpu:

% diff -u ./destroot-arm64/opt/universal/bin/icu-config ./destroot-x86_64/opt/universal/bin/icu-config
--- ./destroot-arm64/opt/universal/bin/icu-config	2021-01-10 17:11:53.000000000 -0500
+++ ./destroot-x86_64/opt/universal/bin/icu-config	2021-01-10 17:11:54.000000000 -0500
@@ -188,9 +188,9 @@
 ##################################################################
 
 # Information about the host that 'configure' was run on.
-host="aarch64-apple-darwin20.3.0"
-host_alias="aarch64-apple-darwin20.3.0"
-host_cpu="aarch64"
+host="x86_64-apple-darwin20.3.0"
+host_alias="x86_64-apple-darwin20.3.0"
+host_cpu="x86_64"
 host_vendor="apple"
 host_os="darwin20.3.0"
 # Our platform canonical name (as determined by configure)

To be honest, this information is none of icu-config's business, so we might argue to just delete it. But then icu-config would not give back anything for this option:

% /opt/universal/bin/icu-config --host       
aarch64-apple-darwin20.3.0

we could write our own bit of shell script to replace that part of icu-config, and branch on the machine:

% uname -m
arm64

I guess that makes the most sense? Looking for some inspiration here from Ryan or similar about what might the right thing to return.

Either way, delete or fix, this looks simple to repair, once we decide what it should return on each system.

[michaelld (Michael Dickens)]

Hmmm ... yeah I remember seeing this issue early on with ARM64 + x86_64. I didn't get this far, so nice job @kencu!

I wonder if any ports that depend on ICU actually use icu-config --host for any information? If not then that makes our lives much easier IMHO! If so then that's an issue since clearly the host can't be both aarch64 and x86_64 ...

[afadini]

So it seems that I am not getting the workaround.

Copying the arm64 icu-config shell script into the x86_64 icu-config did not work for me, as I was telling @kencu

[kencu (Ken)]

What I did was sudo port -v build icu and then go into the source directory cd `port work icu` until I could see the directories as below:

source-arm64
source-x86_64
...

then did this:

sudo cp ./source-arm64/config/icu-config ./source-x86_64/config/icu-config

and then backed out of that and did

sudo port -v install icu

and I was done.

So, just to automate that. To be honest, I'm quite tempted to just NULL out the host information on all the icu-config files, so then they would all match (as nothing). Who cares what the host is anyway? And -- nobody uses icu-config for anything anymore (or they should not) so it's their problem if they want to get the host info from the icu-config anyway...

[potmj (Michael Pot)]

Perhaps

sudo cp -pv ./source-arm64/config/icu-config ./source-x86_64/config/icu-config

Might be better. I think the mv version might only have worked because the ARM version was already built and an

sudo port clean icu 

was not done. The build make continued, first dependency was built, and so it could now continue.

[kencu (Ken)]

of course you're right --I must have cp 'd it. thanks for noticing.

[afadini]

Interestingly, when I do 'sudo port -v build icu' no source-arm64 and source-x86_64 are created in port work icu. Is there maybe a previous step that I am missing?

[Ionic (Mihai Moldovan)]

Yes, you're probably not building +universal?

[afadini]

Ah, it could be. Is there a way to build +universal separately before running 'sudo port -v build icu' ?

[Ionic (Mihai Moldovan)]

sudo port -v clean icu
sudo port -v build icu +universal

as usual. (Note that this will pull in all dependencies as +universal as well, so you might have some rebuilding ahead.)

[afadini]

Of course, you are right about that. Still running into the same issue though. I run:

sudo port -v clean icu
sudo port -v build icu +universal
cd `port work icu`
sudo cp -pv ./source-arm64/config/icu-config ./source-x86_64/config/icu-config
cd ~

Then without cleaning, sudo port -v install icu yields the following error:

Error: Requested variants "" do not match those the build was started with: "+universal". Error: Please use the same variants again, or run 'port clean icu' first to remove the existing partially completed build.

However, running

sudo port -v clean icu

and then

sudo port -v install icu

brings back the error:

Exit code: 1 Error: Failed to destroot icu: icu-config differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_icu/icu/work/destroot-arm64opt/local/bin and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_icu/icu/work/destroot-ppc-intelopt/local/bin and cannot be merged

[Ionic (Mihai Moldovan)]

You'll also need to specify +universal for the install target. That's not done automatically.

[afadini]

Great, that lets the install start. It still finishes with an error however:

x ./opt/local/bin/llvm-cov-mp-7.0 ---> Computing dependencies for cctools. Error: Cannot install cctools for the arch 'arm64' because Error: its dependency llvm-7.0 only supports the archs 'i386 x86_64'. Error: rev-upgrade failed: Error rebuilding gcc8

[Ionic (Mihai Moldovan)]

That error is quite self-explanatory. Something depends upon llvm-7.0, but this port isn't available on the arm64 architecture. I can't tell you which exactly depends on it (at least not easily without a debug log), but you're essentially out of luck on that front.

Usually, this happens if you upgraded from an older version of OS X (and MacPorts tree), which still depends upon older llvm/clang releases. Typically, switching to newer versions gets rid of that, but there isn't an easy do that, this and that step to upgrade. Rather, you'll have to juggle with variants quite a bit, which is... difficult.

[afadini]

A complete wipe of MacPorts and reinstall actually solved the issue it seems. You were right about upgrading from an older version of OS X. Thank you!

[Ionic (Mihai Moldovan)]

Yeah... "we" typically save variants both specified by the user and default (i.e., implicit) variants, but the "default variants" change over time.

However, we do not apply new "default variants" to existing installations, so users have to check all ports regarding their default variants and "upgrade" to the the new default variants manually.

It's a bit difficult to explain (and our documentation regarding this is severely lacking, to the point of non-existent), but that's actually a pretty important point. We just don't advertise it properly.

Sorry for that, I'm actually part of the problem, because, while I know that this is a shortcoming, I never actually took the initiative to document this in the wiki.

[kencu (Ken)]

still trying to sort out what icu-config --host should return for a multi-arch icu library.

--host: In which system the generated program will run.

but there is not just one. There are multiple responses available. Should it return multiple system values? That might indeed make the most sense.

[michaelld (Michael Dickens)]

It should return relative to whatever the runtime "arch" is ...

[kencu (Ken)]

ubuntu doesn't list "host" as an option.

<​http://manpages.ubuntu.com/manpages/xenial/en/man1/icu-config.1.html>

tempting to just delete the host part and leave the rest as is....

[kencu (Ken)]

it's not here either <​https://github.com/unicode-org/icu/blob/master/icu4c/source/config/icu-config-bottom>

[Ionic (Mihai Moldovan)]

Have you asked upstream about it?

I think they only ever have considered one architecture at a time.

Generally, I think that pkg-config files (and stuff like icu-config) should be handled in arch-dependent directories. Many Linux distributions, for instance, have a long history of supporting multi-arch (sometimes called multilib) stuff, splitting files into directories like ${prefix}/lib64 and ${prefix}/lib32 (for x86_64 and x86 architectures).

I believe that MacPorts could do the same, but Apple-based systems are more powerful in the sense that they support fat binaries, which Linux does not. That makes things easier, but also much more complicated if files actually differ...

[potmj (Michael Pot)]

Replying to Ionic:

However, we do not apply new "default variants" to existing installations, so users have to check all ports regarding their default variants and "upgrade" to the the new default variants manually.

Thanks for authoritatively explaining this. It is sort of what I worked out. I guess this means "Rev-upgrade" does not automatically apply any new required variants that are (found) missing. So how do users find all the ports with variant problems?

It seems Apple provide libraries that are very fat, and so I guess users building with the Apple SDK probably don't see any problems. However, I think most of the dylibs built with macports are somewhat less fat, even when +universal is active. I guess there is no easy fix for this, as we now use a range of compilers, which no doubt don't support all archs.

I note in macports.conf we can set the archs that +universal applies to (universal_archs). But in the past, even +universal is not as fat as Apple does for libraries.

[kencu (Ken)]

It's really rusty old default variants carried along that are no longer valid.

you had cctools +llvm7 installed from years ago, but llvm-7.0 isn't supported for the arm64 arch, so you wind up in a bit of a mess trying to install it.

see #46956

[kencu (Ken)]

see <​https://github.com/macports/macports-ports/pull/9742> for a PR that aims to make a practical fix for this.

[kencu (Ken)]

In f0ec05eb0777ca4d3c5c4232edab387ba7a6f2e5/macports-ports (master):

icu: repair multiarch universal build

icu-config embeds host information about the
host that configure ran on. This information is
different for each supported arch, and can't be merged.

icu-config --host
is not mentioned in the icu-config manpages anywhwere
and has no perceived useful purpose

so nullify the arch-specific differences between the
icu-config script to allow a universal icu to be
built once again

the other option would be to write a new icu-config
script that can handle multi-arch logic. What this
script would be expected to output, and how and why
it would be ever used, is not clear, however, so this
option is considered less desirable

closes: #45268

[kencu (Ken)]

new versions of icu are removing icu-config; at present, it is a default-added option, soon to become a default-not-added option:

<​https://unicode-org.atlassian.net/browse/ICU-10464>

So in the near future, we could just disable icu-config completely from being installed. For the older icu versions, we could just delete the file, once we get there.

For now, this fixes the arm64/x86_64 inconsistencies.

I will try the i386/ppc build at some point -- but that version of building +universal is pretty much DOA right now unless/until we get a cross-compiling gcc going again (which we will need soon enough -- but that is another story).

[ryandesign (Ryan Carsten Schmidt)]

You forgot to increase the revision for this change. And your change only fixes the issue with icu-config on some systems. It does not fix the Makefile include issues. See comment:11. If no ports need the Makefile includes, we could remove them, but I don't know if that's the case. And of course it didn't fix the issue for which this ticket was originally filed: i386/ppc universal builds.

[ryandesign (Ryan Carsten Schmidt)]

the other option would be to write a new icu-config script that can handle multi-arch logic.

I don't see how that would be possible, since no caller of icu-config would expect that to be the case. In a normal non-muniversal universal build, icu-config would be called once, and its results must be correct for all of the archs that will be built. In an muniversal universal build, there is no way to inform icu-config what arch we're building for, and if we added one, no existing caller of icu-config would know to do that.

[kencu (Ken)]

Replying to ryandesign:

You forgot to increase the revision for this change.

I will admit it was such an exceedingly trivial change to installed files I purposefully didn't revbump it on everyone, as ICU can be a BEAR to rebuild on older systems.

icu-config no longer puts out a response to an undocumented argument that nobody ever calls.

I just left it un-rev-bumped, and allowed new +universal installs (which never worked before) to work.

I have no issues with revbumping it - please feel free to do so. It was just too trivial for me to do it.

And your change only fixes the issue with icu-config on some systems.

If that is true -- I don't see it. Pleas show me how some systems are being missed.

It does not fix the Makefile include issues.

I was not able to replicate any such issues any longer, icu builds universal nicely with this change. I figured whatever that was, it was GONE now.

And of course it didn't fix the issue for which this ticket was originally filed: i386/ppc universal builds.

Because we have (at present, as I haven't finished it, and may never) no compiler that can compile c++11 code for both i386 and PPC, that particular issue is no longer on the drawing table to be fixed.

[kencu (Ken)]

Replying to ryandesign:

the other option would be to write a new icu-config script that can handle multi-arch logic.

I don't see how that would be possible, since no caller of icu-config would expect that to be the case.

I agree. That option was suggested by some others, so I itemized it here, but I find no use case for it, and it's very hard to see how it could possibly work.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Replying to ryandesign:

You forgot to increase the revision for this change.

I will admit it was such an exceedingly trivial change to installed files I purposefully didn't revbump it on everyone, as ICU can be a BEAR to rebuild on older systems.

icu-config no longer puts out a response to an undocumented argument that nobody ever calls.

I just left it un-rev-bumped, and allowed new +universal installs (which never worked before) to work.

I have no issues with revbumping it - please feel free to do so. It was just too trivial for me to do it.

Sorry, I see you did subsequently revbump in [2382aa2302b01836df2b49125440e0d285b3e573/macports-ports]; thank you.

And your change only fixes the issue with icu-config on some systems.

If that is true -- I don't see it. Pleas show me how some systems are being missed.

See for example ​https://unicode-org.atlassian.net/browse/ICU-21382. The specific problem I was reporting there only shows up when doing a build with archs of different endianness, e.g. ppc/i386, which is what this ticket was about initially, though I have not evaluated the complete contents of icu-config so there might be other arch combinations that would result in similar problems.

It does not fix the Makefile include issues.

I was not able to replicate any such issues any longer, icu builds universal nicely with this change. I figured whatever that was, it was GONE now.

Yes it builds but the contents of the Makefile.inc file that it installs is wrong as I explained in comment:11. To elaborate, Makefile.inc differs by arch as follows:

% diff -u ./destroot-intel/.../lib/icu/67.1/Makefile.inc ./destroot-arm64/.../lib/icu/67.1/Makefile.inc
--- ./destroot-intel/.../lib/icu/67.1/Makefile.inc	2021-02-04 07:36:51.000000000 +0000
+++ ./destroot-arm64/.../lib/icu/67.1/Makefile.inc	2021-02-04 07:36:50.000000000 +0000
@@ -165,9 +165,9 @@
 ##################################################################

 # Information about the host that 'configure' was run on.
-host = x86_64-apple-darwin20.1.0
-host_alias = x86_64-apple-darwin20.1.0
-host_cpu = x86_64
+host = aarch64-apple-darwin20.1.0
+host_alias = aarch64-apple-darwin20.1.0
+host_cpu = aarch64
 host_vendor = apple
 host_os = darwin20.1.0
 # Our platform canonical name (as determined by configure)

It is erroneously merged by the muniversal portgroup as follows:

% grep -C 7 '#else' ./destroot/Users/buildbot/mptest/lib/icu/67.1/Makefile.inc
##################################################################

# Information about the host that 'configure' was run on.
#ifdef __arm64__
host = aarch64-apple-darwin20.1.0
host_alias = aarch64-apple-darwin20.1.0
host_cpu = aarch64
#else
host = x86_64-apple-darwin20.1.0
host_alias = x86_64-apple-darwin20.1.0
host_cpu = x86_64
#endif
host_vendor = apple
host_os = darwin20.1.0
# Our platform canonical name (as determined by configure)

#ifdef, #else, #endif are C preprocessor directives. Makefile.inc is not a file that is processed by the C preprocessor.

Although wrong, I realize now that it's not syntactically invalid. The #ifdef, #else, #endif lines will be interpreted by make as comments and the second of each of the assignments will take precedence. So it's not as bad as I feared: the Makefile.inc isn't unusable, it just has some extra cruft in it, and the values of host/host_alias/host_cpu, which as you say hopefully nobody is using anyway, may be wrong.

We could apply your host/host_alias/host_cpu-removing reinplaces to Makefile.inc as well, and since that would change the content of installed files, it would warrant a revbump. But since the file is usable as is, despite the cruft, and since the file is deprecated and probably disappears in the future anyway, I'm ok with not bothering to dedicate an entire revision just to fixing this. But if we remember to do so, we could include this change the next time the port is updated.

And of course it didn't fix the issue for which this ticket was originally filed: i386/ppc universal builds.

Because we have (at present, as I haven't finished it, and may never) no compiler that can compile c++11 code for both i386 and PPC, that particular issue is no longer on the drawing table to be fixed.

I didn't realize that we could not build C++11 code universal for i386/ppc. I thought we could build C++11 code on pre-libc++ systems using macports-libstdc++ and whatever compiler selection improvements MacPorts base now has. Though perhaps the problem with that is that the gcc compilers we use in that case don't support multiple -arch flags? It has been awhile since I looked at it so I've forgotten.

[kencu (Ken)]

for newer gcc versions, we need to fix two things.

Build a real gcc cross compiler that puts out a new arch, eg arm64 while running on Intel. That would get us going, using the muniversal PG. We have some other gcc cross-compilers in MP we could use for inspiration.

Then, tweak driverdriver.c to again work like Apple's gcc fork did, and like clang does now, allowing multiple arch flags. Then we'd have to use the muniversal PG rarely, like we do now.

Both doable, rather fun, projects that just need an encouraged champion.