[ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts

[Jonathan Wakely]

On 29/08/19 16:54 +0200, Christophe Lyon wrote:
>On 12/07/2019 08:49, Richard Sandiford wrote:
>>Christophe Lyon <christophe.lyon@st.com> writes:
>>>The new arm-uclinuxfdpiceabi target behaves pretty much like
>>>arm-linux-gnueabi. In order the enable the same set of features, we
>>>have to update several configure scripts that generally match targets
>>>like *-*-linux*: in most places, we add *-uclinux* where there is
>>>already *-linux*, or uclinux* when there is already linux*.
>>>
>>>In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi
>>>because there is already a different behaviour for *-*uclinux* target.
>>>
>>>In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
>>>libraries support is required, as uclinux does not guarantee that.
>>>
>>>2019-XX-XX  Christophe Lyon  <christophe.lyon@st.com>
>>>
>>>	config/
>>>	* futex.m4: Handle *-uclinux*.
>>>	* tls.m4 (GCC_CHECK_TLS): Likewise.
>>>
>>>	gcc/
>>>	* config.gcc: Handle *-*-uclinuxfdpiceabi.
>>>
>>>	libatomic/
>>>	* configure.tgt: Handle arm*-*-uclinux*.
>>>	* configure: Regenerate.
>>>
>>>	libgcc/
>>>	* config.host: Handle *-*-uclinuxfdpiceabi.
>>>
>>>	libitm/
>>>	* configure.tgt: Handle *-*-uclinux*.
>>>	* configure: Regenerate.
>>>
>>>	libstdc++-v3/
>>>	* acinclude.m4: Handle uclinux*.
>>>	* configure: Regenerate.
>>>	* configure.host: Handle uclinux*
>>>
>>>	* libtool.m4: Handle uclinux*.
>>
>>Has the libtool.m4 patch been submitted to upstream libtool?
>>I think this is supposed to be handled by submitting there first
>>and then cherry-picking into gcc, so that the change isn't lost
>>by a future import.
>>
>I added a comment to libtool.m4 about this.
>
>>>[...]
>>>
>>>diff --git a/config/tls.m4 b/config/tls.m4
>>>index 1a5fc59..a487aa4 100644
>>>--- a/config/tls.m4
>>>+++ b/config/tls.m4
>>>@@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [
>>>  	  dnl Shared library options may depend on the host; this check
>>>  	  dnl is only known to be needed for GNU/Linux.
>>>  	  case $host in
>>>-	    *-*-linux*)
>>>+	    *-*-linux* | -*-uclinux*)
>>>  	      LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
>>>  	      ;;
>>>  	  esac
>>
>>Is this right for all uclinux targets?
>I don't think so, now restricted to -*-uclinuxfdpic*
>
>>
>>>diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>>>index 84258d8..cb0fdc5 100644
>>>--- a/libstdc++-v3/acinclude.m4
>>>+++ b/libstdc++-v3/acinclude.m4
>>
>>It'd probably be worth splitting out the libstdc++-v3 bits and
>>submitting them separately, cc:ing libstdc++@gcc.gnu.org.  But...
>
>I've now split the patch into two parts (both attached here)
>>
>>>@@ -1404,7 +1404,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
>>>          ac_has_nanosleep=yes
>>>          ac_has_sched_yield=yes
>>>          ;;
>>>-      gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
>>>+      gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*)
>>>          AC_MSG_CHECKING([for at least GNU libc 2.17])
>>>          AC_TRY_COMPILE(
>>>            [#include <features.h>],
>>
>>is this the right thing to do?  It seems odd to be testing the glibc
>>version for uclibc.
>>
>>Do you want to support multiple possible settings of
>>ac_has_clock_monotonic and ac_has_clock_realtime?  Or could you just
>>hard-code the values, given particular baseline assumptions about the
>>version of uclibc etc.?  Hard-coding would then make....
>>
>>>@@ -1526,7 +1526,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
>>>    if test x"$ac_has_clock_monotonic" != x"yes"; then
>>>      case ${target_os} in
>>>-      linux*)
>>>+      linux* | uclinux*)
>>>  	AC_MSG_CHECKING([for clock_gettime syscall])
>>>  	AC_TRY_COMPILE(
>>>  	  [#include <unistd.h>
>>
>>...this redundant.
>>
>Right, now fixed.
>
>>>@@ -2415,7 +2415,7 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
>>>    # Default to "generic".
>>>    if test $enable_clocale_flag = auto; then
>>>      case ${target_os} in
>>>-      linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu)
>>>+      linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*)
>>>  	enable_clocale_flag=gnu
>>>  	;;
>>>        darwin*)
>>
>>This too seems to be choosing a glibc setting for a uclibc target.
>Indeed.
>
>>
>>>@@ -2661,7 +2661,7 @@ AC_DEFUN([GLIBCXX_ENABLE_ALLOCATOR], [
>>>    # Default to "new".
>>>    if test $enable_libstdcxx_allocator_flag = auto; then
>>>      case ${target_os} in
>>>-      linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu)
>>>+      linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*)
>>>  	enable_libstdcxx_allocator_flag=new
>>>  	;;
>>>        *)
>>
>>The full case is:
>>
>>   # Probe for host-specific support if no specific model is specified.
>>   # Default to "new".
>>   if test $enable_libstdcxx_allocator_flag = auto; then
>>     case ${target_os} in
>>       linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu)
>>	enable_libstdcxx_allocator_flag=new
>>	;;
>>       *)
>>	enable_libstdcxx_allocator_flag=new
>>	;;
>>     esac
>>   fi
>>
>>which looks a bit redundant :-)
>
>Right :-)
>
>Thanks,
>
>Christophe
>
>>
>>Thanks,
>>Richard
>>.
>>
>

>From 81c84839b8f004b7b52317850f27f58e05bec6ad Mon Sep 17 00:00:00 2001
>From: Christophe Lyon <christophe.lyon@linaro.org>
>Date: Fri, 4 May 2018 15:11:35 +0000
>Subject: [ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in
> configure scripts
>
>The new arm-uclinuxfdpiceabi target behaves pretty much like
>arm-linux-gnueabi. In order the enable the same set of features, we

s/In order the enable/In order to enable/

The libstdc++ part is OK for trunk.