#45268: icu @53.1_1 +universal: icu-config differs and cannot be merged
-----------------------+--------------------------------
Reporter: nerdling | Owner: macports-tickets@…
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.3.99
Resolution: fixed | Keywords:
Port: icu |
-----------------------+--------------------------------
Comment (by ryandesign):
Replying to [comment:53 kencu]:
> Replying to [comment:50 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.
--
Ticket URL: <https://trac.macports.org/ticket/45268#comment:55>
MacPorts <https://www.macports.org/>
Ports system for macOS