From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.hgst.iphmx.com (esa1.hgst.iphmx.com [68.232.141.245]) by sourceware.org (Postfix) with ESMTPS id 28814385DC01 for ; Tue, 31 Mar 2020 21:11:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 28814385DC01 IronPort-SDR: xlBZkugRa57Cc8bd3h+trlQUuUI6asA+Yh52IKq5hKyxNSCMD1xuMUXiuTzYBlKIt0juA+B/Eh wA+D30yOKC7NGkNmZ7OWABX5iXVRmgNgHq5dwmxtEt5NejymA+YaAKNeoG52Lkgbh28M+TM60u VSuVUpFM1T2VeaPhgrNNpv9ooLKvBBIoCwjBmGocfYgIXkL+2YWvrvtaNhd4qHfPTckY+1dZau WeqrkOZDw2arYDtbHqYnwzt7/juGVGh2uurp/YJ/oaB96gR9R7zVjCzgVYoPe+ODGRHfwXesk9 aCA= X-IronPort-AV: E=Sophos;i="5.72,329,1580745600"; d="scan'208";a="242659567" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 01 Apr 2020 05:11:12 +0800 IronPort-SDR: FOmmMRjn5Y++31ROWJFieTYaiMfSQqF7a2IjNjtKgqtsQOtN6qlvT8qH0qZdoqTpNkUcvMH9+f eUbJIgvOYj/R44i/CBpkpXQ4/CfJWWi2GtFYsSnVhYgrszAHnmqsMFxVQwsqd5mGFAKx96awRT P5XZPwAxBMColNG1PI3BZX2IBftZruiMNqfId/Se5k44j4KWzDO+baSQfI+gkY6wPEcIGp3eSh PHZUKPC5tWI7QRPq0LAXyrRnZeBisW9PiYRogD4u42ElLuLWtf/267q6PFhudTKYD5D6uxEM16 soIEqXBTHA1Nb2FRKJd9fd/R Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2020 14:02:39 -0700 IronPort-SDR: QT0oLZHLM+21gQmRf70e6tBCO9UdoKqabGWacuWrU4vBO2jndx1rGYsI7p7SvSW14CBfDY58TO Db4IC1xDcygRoNitC+go2zYWCuoAz8twdV+heULazJ+9c/ri/KewkZ3CPScbVRV/7tVcgV+kC8 4xsRFYXTm/2odp6kXodN2mpRT0rB8KKqNKeiI7CIKR/GpSG1w6hm3Pi4u3vGU3foEpN1V1UR3t 7pxlqj1EbRXDWn6y7nmeAkyXvEuD3bfHxXDzEkCj9F8ssno+Y8KrIzXfd2d4gpy+jcCWZNqxVT AF0= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2020 14:11:10 -0700 Date: Tue, 31 Mar 2020 22:11:04 +0100 (BST) From: "Maciej W. Rozycki" To: Mike Stump , Richard Henderson cc: "H.J. Lu" , Jeffrey Law , GCC Patches , Julian Brown , Tobias Burnus , Thomas Schwinge , Chung-Lin Tang , Ian Lance Taylor , libffi-discuss@sourceware.org Subject: Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot In-Reply-To: <7A59EACC-C414-4278-8BEC-F0D02792E62F@comcast.net> Message-ID: References: <805572B0-892A-4811-8CB3-762023C8703F@comcast.net> <7A59EACC-C414-4278-8BEC-F0D02792E62F@comcast.net> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 21:11:17 -0000 On Mon, 30 Mar 2020, Mike Stump wrote: > > I have actually considered extracting the bits already, but I hesitated > > putting that forward that as having looked at the part that we require I > > have thought it to be very messy: > > Yeah, sometimes it's like that. I glanced at the work, if you think > it's a step forward, I'd support importing it, my take, import from > upstream isn't a bad way to go. So I looked into it some more and interestingly enough all the commits I have listed in the previous message have already been made as of libffi's commit c82cc159426d ("Merge pull request #166 from chevah/master") that we imported with our commit b1760f7f915a ("Merge libffi to upstream commit c82cc159426d8d4402375fa1ae3f045b9cf82e16"). That merge was extensively discussed starting from: , however no mention was as to why the local.exp part had been omitted from the merge. Perhaps it was considered not necessary for integrating with the GCC tree, although I would think that keeping the divergence to the minimum is preferable, and it looks to me that our requirements boil down essentially to adding multilib support and making some further, minor tweaks to match the rest of the tree. Whereas the diff between the Makefile systems as at libffi's commit c82cc159426d and our commit b1760f7f915a looks to me quite substantial. Perhaps Richard will be able to provide some input here. > > So I am in favour of retaining the mechanism rather than using my earlier > > proposal, however I'm in two minds as to how to proceed. Integrating the > > change as it is will make us having clutter left in the tree after `make > > distclean', but we can do it right away. > > I'd support this. distclean is one rm -rf away from being clean enough. > I'd not let that gate or hold up the import. While doing further work on finding a solution that would be acceptable (to me anyway), I actually found two further upstream libffi commits: - commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"), - commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES"), both beyond our merge point, that fix this shortcoming. Still there's no Makefile dependency, so if configure.ac is patched or local.exp removed, then it is not regenerated, and all that would not be required if what automake provides was used. > If there is work that we want that's more to do with in tree building > and testing (sys root fun, multilibs), while not ideal, we can deviate > from upstream to support that. Though, if there is a way to naturally > support that, that upstream can accept, that'd be better. I did some work now to reduce the divergence and will be posting patch series shortly to both upstream libffi and our version. Hopefully that'll be acceptable, at least the initial, minimal change from each series. If not, for a reference, here's an updated version of the patch I posted last time. It includes the two upstream libffi commits I have mentioned above. Let's see how it goes. Thank you for your input. Maciej --- libffi/Makefile.am | 3 +++ libffi/Makefile.in | 4 ++++ libffi/configure | 5 +++++ libffi/configure.ac | 5 +++++ libffi/testsuite/Makefile.am | 2 ++ libffi/testsuite/Makefile.in | 1 + 6 files changed, 20 insertions(+) gcc-test-libffi-cc-for-target.diff Index: gcc/libffi/Makefile.am =================================================================== --- gcc.orig/libffi/Makefile.am +++ gcc/libffi/Makefile.am @@ -15,6 +15,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change libffi.xcodeproj/project.pbxproj \ libtool-ldflags +# local.exp is generated by configure +DISTCLEANFILES = local.exp + # Automake Documentation: # If your package has Texinfo files in many directories, you can use the # variable TEXINFO_TEX to tell Automake where to find the canonical Index: gcc/libffi/Makefile.in =================================================================== --- gcc.orig/libffi/Makefile.in +++ gcc/libffi/Makefile.in @@ -454,6 +454,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change libtool-ldflags +# local.exp is generated by configure +DISTCLEANFILES = local.exp + # Automake Documentation: # If your package has Texinfo files in many directories, you can use the # variable TEXINFO_TEX to tell Automake where to find the canonical @@ -1674,6 +1677,7 @@ installcheck: installcheck-recursive -rm -f src/x86/$(am__dirstamp) -rm -f src/xtensa/$(DEPDIR)/$(am__dirstamp) -rm -f src/xtensa/$(am__dirstamp) + -test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" Index: gcc/libffi/configure =================================================================== --- gcc.orig/libffi/configure +++ gcc/libffi/configure @@ -14961,6 +14961,11 @@ _ACEOF +cat > local.exp <&5 $as_echo_n "checking whether to enable maintainer-specific portions of Makefiles... " >&6; } Index: gcc/libffi/configure.ac =================================================================== --- gcc.orig/libffi/configure.ac +++ gcc/libffi/configure.ac @@ -61,6 +61,11 @@ AC_PROG_LIBTOOL # Test for 64-bit build. AC_CHECK_SIZEOF([size_t]) +cat > local.exp <