public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@wdc.com>
To: libffi-discuss@sourceware.org
Cc: Anthony Green <green@moxielogic.com>,
	Mike Stump <mikestump@comcast.net>,
	 gcc-patches@gcc.gnu.org
Subject: [PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite
Date: Fri, 3 Apr 2020 23:55:10 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.21.2004012222200.461@redsun52.ssa.fujisawa.hgst.com> (raw)

Hi,

 In the course of a discussion at one of the GCC mailing lists here: 
<https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542761.html> I have 
realised that some parts related to libffi testing have not been merged to 
GCC, and they are needed to choose the right compiler in a cross-compiler 
build environment where the build root option has been used.

 Additionally the right target run-time loader's library path has to be 
set via the LD_LIBRARY_PATH environment variable for running the test 
suite in a cross-compilation environment where the location of the host 
libraries is obviously irrelevant.

 We are keen to keep the GCC's copy of libffi as close as possible to the 
upstream version however while usable the current solution has some issues 
which we would rather avoid.  I have therefore decided to address some of 
them with the intent to have the result backported to GCC.  As it stands 
I'm told the current version of libffi cannot be fully merged to GCC, as 
there have been an ABI change that will require technical evaluation.  So 
the intent has been to backport the changes proposed here individually.

 See the individual change descriptions and any further discussion 
included for full details of each patch proposed.

 These changes have been regression-tested with the `x86_64-linux-gnu' 
native configuration, and also the `x86_64-linux-gnu' host and the 
`riscv64-linux-gnu' target using RISC-V QEMU in the Linux user emulation 
mode as the target board.  In the latter case I actually dropped libffi 
into GCC as a replacement of the version included there, with a minor 
update like below (+script regeneration) to add multilib support.

 Any questions, comments, or concerns?  Otherwise, please apply.

  Maciej

Index: gcc/libffi/Makefile.am
===================================================================
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -2,7 +2,7 @@
 
 AUTOMAKE_OPTIONS = foreign subdir-objects
 
-ACLOCAL_AMFLAGS = -I m4
+ACLOCAL_AMFLAGS = -I m4 -I ../config
 
 SUBDIRS = include testsuite man
 if BUILD_DOCS
@@ -158,3 +158,12 @@ AM_CCASFLAGS = $(AM_CPPFLAGS)
 	if [ -d $(top_srcdir)/.git ] ; then (cd $(top_srcdir); git log --no-decorate) ; else echo 'See git log for history.' ; fi > $(distdir)/ChangeLog
 	s=`awk '/was released on/{ print NR; exit}' $(top_srcdir)/README.md`; tail -n +$$(($$s-1)) $(top_srcdir)/README.md > $(distdir)/README.md
 
+# Multilib support.  Automake should provide these on its own.
+all-recursive: all-multi
+install-recursive: install-multi
+mostlyclean-recursive: mostlyclean-multi
+clean-recursive: clean-multi
+distclean-recursive: distclean-multi
+maintainer-clean-recursive: maintainer-clean-multi
+
+include $(top_srcdir)/../multilib.am
Index: gcc/libffi/configure.ac
===================================================================
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -5,6 +5,8 @@ AC_PREREQ(2.68)
 AC_INIT([libffi], [3.3], [http://github.com/libffi/libffi/issues])
 AC_CONFIG_HEADERS([fficonfig.h])
 
+AM_ENABLE_MULTILIB(, ..)
+
 AC_CANONICAL_SYSTEM
 target_alias=${target_alias-$host_alias}
 

             reply	other threads:[~2020-04-03 22:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:55 Maciej W. Rozycki [this message]
2020-04-03 22:55 ` [PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU Maciej W. Rozycki
2020-04-06 17:58   ` Jeff Law
2020-04-03 22:55 ` [PATCH libffi 2/4] Use a documented way to pass $compiler_vendor " Maciej W. Rozycki
2020-04-06 18:00   ` Jeff Law
2020-04-03 22:56 ` [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET Maciej W. Rozycki
2020-04-06 18:03   ` Jeff Law
2020-04-03 22:56 ` [PATCH libffi 4/4] Correct indentation throughout `libffi-init' Maciej W. Rozycki
2020-04-06 18:01   ` Jeff Law
2020-04-14 13:59 ` [PING][PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite Maciej W. Rozycki
2020-04-20 12:50 ` [PING^2][PATCH " Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.2004012222200.461@redsun52.ssa.fujisawa.hgst.com \
    --to=macro@wdc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=green@moxielogic.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=mikestump@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).