From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.hgst.iphmx.com (esa2.hgst.iphmx.com [68.232.143.124]) by sourceware.org (Postfix) with ESMTPS id A0C48385E006 for ; Thu, 26 Mar 2020 22:00:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A0C48385E006 IronPort-SDR: 3uKSMU25xAhFOVZWnt4k2OjDbiIoEsaNV9ZcYYEf+8aFsz9tw1mYBJ6E03iAgaps1W1I/57e+q PEkczWNzpY6JHrMNuOY0+Nxn8XlrhGd4d5sYCiJrZmLRyWXLoplRPnV0EJJU9SpwY/GLXyhdc3 VoM7efQYSW9USk+7WnEvVBACL9+hNZgUM/QVquIJPTlp4h3yHjtIMvCHtLC1MfStV9AoI/6Ypd Ll9BbctQArwoAcVN/BGDyaZ4K+Bdz3kL8zuERnsJ0IdFoi9sBX8xffv5FDzLumJZltjJJblwHL 6v4= X-IronPort-AV: E=Sophos;i="5.72,309,1580745600"; d="scan'208";a="235854279" Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 27 Mar 2020 06:00:40 +0800 IronPort-SDR: dNElKvRNivBCEYvcxzCRdbHKWuhts7W4962/CGhJZu4Trqs8undEAKQWSgOvHRjwTHUi9fBuoK qMyTEmI6CSZ5Jh7PQFIXbtTASCTQfOdXVZFGyXD9jysVbk6PdrQFWfbfreLKb2Y+oX1270d21/ NOs3b/fcPJ7LNKQZsDhlbizBKZBYpnGR/vaGIJsQx8QXpyEWVaGQ+FEw6Y1hVSoGPAuCNVph+J KKaDYWQte51ZA562l3j8e5IaJsx7QvyZowGN68izyH+7otdnEEMyD0U5xZWYK4HcybRuV+4YBv Q3FCd4Iv1diLvm9w2ygpdnc/ Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 14:51:20 -0700 IronPort-SDR: 6/mtveq+45yImbzoWjdksGzkVzcYAr3cUPmZJNN1msC2J0er+NM15LG2nahoCjILlDBILHWHxD ZLNcGmLXbSoGkZ9dCmhOWDd6aOrF3YiB5WhAD9RJcsLzmPiW+Wtgcrj7EF/aDGGksWgGi8B1dr SJ3k5YdAWLxV3+Rrz2lLEPQBaP//NhCxNVDdvmlhO3P7hUENyBbBqmFXY6xQ54i7KOC2KkiC8A x1HeB9fK8aSYtiarygaiMbCGrKEXMl8tj2Fxkh4zq9HfRhH0DgWl6mEnTXaNYnyM/8i2VsRFU3 weA= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 15:00:16 -0700 Date: Thu, 26 Mar 2020 22:00:11 +0000 (GMT) From: "Maciej W. Rozycki" To: Mike Stump 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: <805572B0-892A-4811-8CB3-762023C8703F@comcast.net> Message-ID: References: <805572B0-892A-4811-8CB3-762023C8703F@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.8 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, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Thu, 26 Mar 2020 22:00:23 -0000 On Tue, 24 Mar 2020, Mike Stump wrote: > > Have we made any conclusions WRT the way to move forward with this stuff? > > Things remain broken and I'd prefer to get the issues off the plate while > > the stuff is hot, or at least mildly warm. I'm about to get distracted > > with other work. > > It's unfortunate that upstream has anything that prevents it from us > just importing it all and calling it done. > > Anyway, if you see a path forward for grabbing all the Makefile/config > stuff and leaving the abi changing stuff out, and just important that, > we can do a partial import. I say this without reviewing the diffs from > upstream and how many there are and what's in them. I'm hoping things > are nicely segregated and reasonably small otherwise. Thank you for your input. 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: the .exp file is handcrafted with an inline piece of scriptery buried in `configure.ac' and never cleaned, not even with `make distclean', nor equipped with any Makefile dependencies. Clearly it must have been written by someone who hasn't been accustomed to working with GNU autotools. The ultimate change is very small, but it has only been created gradually with four commits in the upstream libffi repository, none of which applies cleanly to ours and most of which include unrelated stuff. They are: - commit 8308984e479e ("[PATCH] Make sure we're running dejagnu tests with the right compiler."), - commit 2d9b3939751b ("[PATCH] Fix for closures with sunpro compiler"), - commit 0c3824702d3d ("[PATCH] Always set CC_FOR_TARGET for dejagnu, to make the testsuite respect $CC"), - commit 7d698125b1f0 ("[PATCH] Use the proper C++ compiler to run C++ tests") -- not yet needed in our libffi version as no tests are marked C++. -- at . I have now extracted the relevant bits from the four commits and the result is below. I have pushed it through my testing and it fixes the test results just like my earlier proposal; in fact libffi.log files are the same modulo timestamps and one number that is randomly generated. It is worth noting however that the multilib discovery logic in `libffi-init' has not been updated unlike with my proposal and it continues using the compiler hardcoded within rather than one set with CC_FOR_TARGET/CXX_FOR_TARGET. That uses a mechanism (*_FOR_TARGET, interpreted within `target_compile') different from one we do (*_UNDER_TEST, used to set `compiler=' in the invocation of `target_compile'), and ignores TOOL_EXECUTABLE altogether. It makes sense however semantically to me for a standalone library test suite to consider the compiler just a tool in testing and not the object under test. Plus it makes it easy to define compilers for the various languages required. 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. Fixing the problems with the change upstream in libffi first and then merging the result back into our tree will avoid getting the clutter, but will likely take time. I'll sleep on it yet, and meanwhile I'll be happy to hear suggestions. I have also cc-ed the libffi mailing list for a possible further insight. Maciej --- libffi/configure | 5 +++++ libffi/configure.ac | 5 +++++ libffi/testsuite/Makefile.am | 2 ++ libffi/testsuite/Makefile.in | 1 + 4 files changed, 13 insertions(+) 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 <