#45268 closed defect (fixed)
icu @53.1_1 +universal: icu-config differs and cannot be merged
Reported by: | nerdling (Jeremy Lavergne) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.99 |
Keywords: | Cc: | potmj (Michael Pot), Ionic (Mihai Moldovan), jpanetta (Julian Panetta), MaddTheSane (C.W. Betts), michaelld (Michael Dickens), kencu (Ken), ryandesign (Ryan Carsten Schmidt) | |
Port: | icu |
Description
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
Attachments (1)
Change History (58)
Changed 10 years ago by nerdling (Jeremy Lavergne)
Attachment: | icu.log.xz added |
---|
comment:1 Changed 10 years ago by nerdling (Jeremy Lavergne)
comment:3 Changed 10 years ago by 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.
comment:4 Changed 10 years ago by Ionic (Mihai Moldovan)
Cc: | ionic@… added |
---|
comment:5 Changed 10 years ago by 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.
comment:6 follow-up: 7 Changed 10 years ago by 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.
comment:7 Changed 10 years ago by larryv (Lawrence Velázquez)
Perhaps the port could just disallow Intel+PPC builds?
comment:8 Changed 10 years ago by 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.
comment:9 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign removed |
---|
comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | icu @53.1_1 +universal 10.5 destroot failure → icu @53.1_1 +universal: icu-config differs and cannot be merged |
---|
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.
comment:11 Changed 4 years ago by 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.
comment:12 follow-up: 18 Changed 4 years ago by 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
comment:13 Changed 4 years ago by jpanetta (Julian Panetta)
Cc: | jpanetta added |
---|
comment:14 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:15 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld removed |
---|
comment:16 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:17 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | MaddTheSane added |
---|
Has duplicate #61677.
comment:18 Changed 4 years ago by 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 asupported_arches
omittingarm64
inllvm-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.)
comment:19 Changed 4 years ago by maralski (Peter Marelas)
Yeah I am seeing the same icu-config issue with Apple Silicon trying to install KeePassXC.
comment:20 Changed 4 years ago by 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
comment:21 Changed 4 years ago by ddennedy (Dan Dennedy)
Cc: | ddennedy added |
---|
comment:22 Changed 4 years ago by 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.
comment:23 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld removed |
---|
comment:24 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:25 Changed 4 years ago by 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
...
comment:26 Changed 4 years ago by 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
comment:27 Changed 4 years ago by 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...
comment:28 Changed 4 years ago by 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.
comment:29 Changed 4 years ago by kencu (Ken)
of course you're right --I must have cp 'd it. thanks for noticing.
comment:30 Changed 4 years ago by 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?
comment:31 Changed 4 years ago by Ionic (Mihai Moldovan)
Yes, you're probably not building +universal
?
comment:32 Changed 4 years ago by afadini
Ah, it could be. Is there a way to build +universal separately before running 'sudo port -v build icu' ?
comment:33 Changed 4 years ago by 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.)
comment:34 Changed 4 years ago by 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
comment:35 Changed 4 years ago by Ionic (Mihai Moldovan)
You'll also need to specify +universal
for the install target. That's not done automatically.
comment:36 Changed 4 years ago by 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
comment:37 Changed 4 years ago by 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.
comment:38 Changed 4 years ago by 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!
comment:39 follow-up: 45 Changed 4 years ago by 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.
comment:40 Changed 4 years ago by 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.
comment:41 Changed 4 years ago by michaelld (Michael Dickens)
It should return relative to whatever the runtime "arch" is ...
comment:42 Changed 4 years ago by 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....
comment:43 Changed 4 years ago by kencu (Ken)
it's not here either <https://github.com/unicode-org/icu/blob/master/icu4c/source/config/icu-config-bottom>
comment:44 Changed 4 years ago by 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...
comment:45 Changed 4 years ago by 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.
comment:46 Changed 4 years ago by 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
comment:47 Changed 4 years ago by kencu (Ken)
see <https://github.com/macports/macports-ports/pull/9742> for a PR that aims to make a practical fix for this.
comment:48 Changed 4 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:49 Changed 4 years ago by 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).
comment:50 follow-up: 53 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | kencu added |
---|
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.
comment:51 follow-up: 54 Changed 4 years ago by 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.
comment:52 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign added |
---|
comment:53 follow-up: 55 Changed 4 years ago by 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.
comment:54 Changed 4 years ago by 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.
comment:55 Changed 4 years ago by 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. I was working my way through old commit messages and didn't realize.
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/.../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.
comment:56 Changed 4 years ago by 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.
comment:57 Changed 4 years ago by ddennedy (Dan Dennedy)
Cc: | ddennedy removed |
---|
The -config files differ regarding endian/architecture: