On 29/08/19 16:54 +0200, Christophe Lyon wrote:
On 12/07/2019 08:49, Richard Sandiford wrote:
Christophe Lyon <christophe.l...@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.l...@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 libstd...@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.l...@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.



Reply via email to