Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Christophe Lyon writes:
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index c7a464c..721729d 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1167,7 +1167,7 @@ arm*-*-netbsdelf*)
> tmake_file="${tmake_file} arm/t-arm"
> target_cpu_cname="strongarm"
> ;;
> -arm*-*-linux-*) # ARM GNU/Linux with ELF
> +arm*-*-linux-* | arm*-*-uclinuxfdpiceabi)# ARM GNU/Linux
> with ELF
> tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
> glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
> extra_options="${extra_options} linux-android.opt"
> case $target in
Better to remove the "# ARM GNU/Linux with ELF" comment too, since it
doesn't cover the new case and was already misleading given the
bionic support.
> diff --git a/libgcc/config.host b/libgcc/config.host
> index 91abc84..facca2a 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -435,7 +435,7 @@ arm*-*-fuchsia*)
> arm*-*-netbsdelf*)
> tmake_file="$tmake_file arm/t-arm arm/t-netbsd t-slibgcc-gld-nover"
> ;;
> -arm*-*-linux*) # ARM GNU/Linux with ELF
> +arm*-*-linux* | arm*-*-uclinuxfdpiceabi) # ARM GNU/Linux
> with ELF
> tmake_file="${tmake_file} arm/t-arm t-fixedpoint-gnu-prefix t-crtfm"
> tmake_file="${tmake_file} arm/t-elf arm/t-bpabi arm/t-linux-eabi
> t-slibgcc-libgcc"
> tm_file="$tm_file arm/bpabi-lib.h"
Same here.
OK with those changes, thanks.
Richard
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On Fri, 30 Aug 2019 at 16:49, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Fri, 30 Aug 2019 at 11:00, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > @@ -785,7 +785,7 @@ case ${target} in
> >> >esac
> >> >tmake_file="t-slibgcc"
> >> >case $target in
> >> > -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
> >> > *-*-kopensolaris*-gnu)
> >> > +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
> >> > *-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
> >> >:;;
> >> > *-*-gnu*)
> >> >native_system_header_dir=/include
> >>
> >> I don't think this is necessary, since this target will never match the
> >> following *-*-gnu*) stanza anyway.
> > OK (I thought it was clearer to add the fdpic config where we already
> > have linux that would not match)
>
> I think the idea is to match pure GNU systems only in the second stanza
> (i.e. GNU/Hurd). So we need the first stanza to exclude hybrid-GNU
> systems like GNU/Linux, GNU/Solaris, GNU/FreeBSD, etc.
>
> Since uclinuxfdpiceabi isn't a GNU-based system, I don't think it
> needs to appear at all.
>
> >> > diff --git a/libtool.m4 b/libtool.m4
> >> > index 8966762..64e507a 100644
> >> > --- a/libtool.m4
> >> > +++ b/libtool.m4
> >> > @@ -3734,7 +3739,7 @@ m4_if([$1], [CXX], [
> >> > ;;
> >> > esac
> >> > ;;
> >> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> >> > case $cc_basename in
> >> > KCC*)
> >> > # KAI C++ Compiler
> >>
> >> Is this needed? It seems to be in the !GCC branch of an if/else.
> > I must admit I didn't test this case. I thought it was needed because
> > this target does not match "linux*", in case someone tries to compile
> > with another compiler...
> >
> >
> >>
> >> If it is needed, the default:
> >>
> >> _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
> >>
> >> seems correct for non-FDPIC uclinux.
> >>
> > So, either use uclinuxfdpiceabi above, or do nothing and do not try to
> > support other compilers?
>
> Yeah. I think the latter's better, since in this context we only
> need libtool.m4 to support building with GCC. The decision might
> be different for upstream libtool, but do any commercial compilers
> support Arm FDPIC yet?
>
> >> > @@ -4032,7 +4037,7 @@ m4_if([$1], [CXX], [
> >> >_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
> >> >;;
> >> >
> >> > -linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > +linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> >> >case $cc_basename in
> >> ># old Intel for x86_64 which still supported -KPIC.
> >> >ecc*)
> >>
> >> Same here.
> >>
> >> > @@ -5946,7 +5951,7 @@ if test "$_lt_caught_CXX_error" != yes; then
> >> > _LT_TAGVAR(inherit_rpath, $1)=yes
> >> > ;;
> >> >
> >> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
> >> > case $cc_basename in
> >> >KCC*)
> >> > # Kuck and Associates, Inc. (KAI) C++ Compiler
> >>
> >> Here too the code seems to be dealing specifically with non-GCC compilers.
> >>
> >> > @@ -6598,7 +6603,7 @@ interix[[3-9]]*)
> >> >_LT_TAGVAR(postdeps,$1)=
> >> >;;
> >> >
> >> > -linux*)
> >> > +linux* | uclinux*)
> >> >case `$CC -V 2>&1 | sed 5q` in
> >> >*Sun\ C*)
> >> > # Sun C++ 5.9
> >>
> >> Here too. (It only seems to do anything for Sun's C compiler.)
> >>
> >> The fewer hunks we have to maintain downstream the better :-)
> >>
> > Sure.
> >
> > I thought safer/cleaner to prepare the cases for non-GCC compilers, I
> > guess it's better not to add that until proven useful?
>
> Yeah, I think so. I guess it depends on your POV. To me, it seems
> cleaner to add uclinux* and uclinuxfdpiceabi only where we know there's
> a specific need, since that's also how we decide which of uclinux* and
> uclinuxfdpiceabi to use.
>
OK, here is an updated version of this patch.
Christophe
> Thanks,
> Richard
commit 0dbd18d60be654fa2ff2ae85670cc096db5217a5
Author: Christophe Lyon
Date: Fri May 4 15:11:35 2018 +
[ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
The new arm-uclinuxfdpiceabi target behaves pretty much like
arm-linux-gnueabi. In order to 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
config/
* futex.m4:
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Christophe Lyon writes:
> On Fri, 30 Aug 2019 at 11:00, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > @@ -785,7 +785,7 @@ case ${target} in
>> >esac
>> >tmake_file="t-slibgcc"
>> >case $target in
>> > -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
>> > *-*-kopensolaris*-gnu)
>> > +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu |
>> > *-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
>> >:;;
>> > *-*-gnu*)
>> >native_system_header_dir=/include
>>
>> I don't think this is necessary, since this target will never match the
>> following *-*-gnu*) stanza anyway.
> OK (I thought it was clearer to add the fdpic config where we already
> have linux that would not match)
I think the idea is to match pure GNU systems only in the second stanza
(i.e. GNU/Hurd). So we need the first stanza to exclude hybrid-GNU
systems like GNU/Linux, GNU/Solaris, GNU/FreeBSD, etc.
Since uclinuxfdpiceabi isn't a GNU-based system, I don't think it
needs to appear at all.
>> > diff --git a/libtool.m4 b/libtool.m4
>> > index 8966762..64e507a 100644
>> > --- a/libtool.m4
>> > +++ b/libtool.m4
>> > @@ -3734,7 +3739,7 @@ m4_if([$1], [CXX], [
>> > ;;
>> > esac
>> > ;;
>> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
>> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
>> > case $cc_basename in
>> > KCC*)
>> > # KAI C++ Compiler
>>
>> Is this needed? It seems to be in the !GCC branch of an if/else.
> I must admit I didn't test this case. I thought it was needed because
> this target does not match "linux*", in case someone tries to compile
> with another compiler...
>
>
>>
>> If it is needed, the default:
>>
>> _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
>>
>> seems correct for non-FDPIC uclinux.
>>
> So, either use uclinuxfdpiceabi above, or do nothing and do not try to
> support other compilers?
Yeah. I think the latter's better, since in this context we only
need libtool.m4 to support building with GCC. The decision might
be different for upstream libtool, but do any commercial compilers
support Arm FDPIC yet?
>> > @@ -4032,7 +4037,7 @@ m4_if([$1], [CXX], [
>> >_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
>> >;;
>> >
>> > -linux* | k*bsd*-gnu | kopensolaris*-gnu)
>> > +linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
>> >case $cc_basename in
>> ># old Intel for x86_64 which still supported -KPIC.
>> >ecc*)
>>
>> Same here.
>>
>> > @@ -5946,7 +5951,7 @@ if test "$_lt_caught_CXX_error" != yes; then
>> > _LT_TAGVAR(inherit_rpath, $1)=yes
>> > ;;
>> >
>> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
>> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
>> > case $cc_basename in
>> >KCC*)
>> > # Kuck and Associates, Inc. (KAI) C++ Compiler
>>
>> Here too the code seems to be dealing specifically with non-GCC compilers.
>>
>> > @@ -6598,7 +6603,7 @@ interix[[3-9]]*)
>> >_LT_TAGVAR(postdeps,$1)=
>> >;;
>> >
>> > -linux*)
>> > +linux* | uclinux*)
>> >case `$CC -V 2>&1 | sed 5q` in
>> >*Sun\ C*)
>> > # Sun C++ 5.9
>>
>> Here too. (It only seems to do anything for Sun's C compiler.)
>>
>> The fewer hunks we have to maintain downstream the better :-)
>>
> Sure.
>
> I thought safer/cleaner to prepare the cases for non-GCC compilers, I
> guess it's better not to add that until proven useful?
Yeah, I think so. I guess it depends on your POV. To me, it seems
cleaner to add uclinux* and uclinuxfdpiceabi only where we know there's
a specific need, since that's also how we decide which of uclinux* and
uclinuxfdpiceabi to use.
Thanks,
Richard
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On Fri, 30 Aug 2019 at 11:00, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > @@ -785,7 +785,7 @@ case ${target} in
> >esac
> >tmake_file="t-slibgcc"
> >case $target in
> > -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> > +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu
> > | *-*-uclinuxfdpiceabi)
> >:;;
> > *-*-gnu*)
> >native_system_header_dir=/include
>
> I don't think this is necessary, since this target will never match the
> following *-*-gnu*) stanza anyway.
OK (I thought it was clearer to add the fdpic config where we already
have linux that would not match)
>
> > diff --git a/libtool.m4 b/libtool.m4
> > index 8966762..64e507a 100644
> > --- a/libtool.m4
> > +++ b/libtool.m4
> > @@ -3734,7 +3739,7 @@ m4_if([$1], [CXX], [
> > ;;
> > esac
> > ;;
> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> > case $cc_basename in
> > KCC*)
> > # KAI C++ Compiler
>
> Is this needed? It seems to be in the !GCC branch of an if/else.
I must admit I didn't test this case. I thought it was needed because
this target does not match "linux*", in case someone tries to compile
with another compiler...
>
> If it is needed, the default:
>
> _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
>
> seems correct for non-FDPIC uclinux.
>
So, either use uclinuxfdpiceabi above, or do nothing and do not try to
support other compilers?
> > @@ -4032,7 +4037,7 @@ m4_if([$1], [CXX], [
> >_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
> >;;
> >
> > -linux* | k*bsd*-gnu | kopensolaris*-gnu)
> > +linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> >case $cc_basename in
> ># old Intel for x86_64 which still supported -KPIC.
> >ecc*)
>
> Same here.
>
> > @@ -5946,7 +5951,7 @@ if test "$_lt_caught_CXX_error" != yes; then
> > _LT_TAGVAR(inherit_rpath, $1)=yes
> > ;;
> >
> > - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> > + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
> > case $cc_basename in
> >KCC*)
> > # Kuck and Associates, Inc. (KAI) C++ Compiler
>
> Here too the code seems to be dealing specifically with non-GCC compilers.
>
> > @@ -6598,7 +6603,7 @@ interix[[3-9]]*)
> >_LT_TAGVAR(postdeps,$1)=
> >;;
> >
> > -linux*)
> > +linux* | uclinux*)
> >case `$CC -V 2>&1 | sed 5q` in
> >*Sun\ C*)
> > # Sun C++ 5.9
>
> Here too. (It only seems to do anything for Sun's C compiler.)
>
> The fewer hunks we have to maintain downstream the better :-)
>
Sure.
I thought safer/cleaner to prepare the cases for non-GCC compilers, I
guess it's better not to add that until proven useful?
Thanks,
Christophe
> Richard
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On 29/08/19 16:54 +0200, Christophe Lyon wrote:
On 12/07/2019 08:49, Richard Sandiford wrote:
Christophe Lyon 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
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 ],
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
...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
Date: Fri, 4 May 2018 15:11:35 +
Subject: [ARM/FDPIC v6 02/24] [ARM] FDPIC: Han
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Christophe Lyon writes:
> @@ -785,7 +785,7 @@ case ${target} in
>esac
>tmake_file="t-slibgcc"
>case $target in
> -*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu
> | *-*-uclinuxfdpiceabi)
>:;;
> *-*-gnu*)
>native_system_header_dir=/include
I don't think this is necessary, since this target will never match the
following *-*-gnu*) stanza anyway.
> diff --git a/libtool.m4 b/libtool.m4
> index 8966762..64e507a 100644
> --- a/libtool.m4
> +++ b/libtool.m4
> @@ -3734,7 +3739,7 @@ m4_if([$1], [CXX], [
> ;;
> esac
> ;;
> - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> case $cc_basename in
> KCC*)
> # KAI C++ Compiler
Is this needed? It seems to be in the !GCC branch of an if/else.
If it is needed, the default:
_LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
seems correct for non-FDPIC uclinux.
> @@ -4032,7 +4037,7 @@ m4_if([$1], [CXX], [
>_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
>;;
>
> -linux* | k*bsd*-gnu | kopensolaris*-gnu)
> +linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
>case $cc_basename in
># old Intel for x86_64 which still supported -KPIC.
>ecc*)
Same here.
> @@ -5946,7 +5951,7 @@ if test "$_lt_caught_CXX_error" != yes; then
> _LT_TAGVAR(inherit_rpath, $1)=yes
> ;;
>
> - linux* | k*bsd*-gnu | kopensolaris*-gnu)
> + linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
> case $cc_basename in
>KCC*)
> # Kuck and Associates, Inc. (KAI) C++ Compiler
Here too the code seems to be dealing specifically with non-GCC compilers.
> @@ -6598,7 +6603,7 @@ interix[[3-9]]*)
>_LT_TAGVAR(postdeps,$1)=
>;;
>
> -linux*)
> +linux* | uclinux*)
>case `$CC -V 2>&1 | sed 5q` in
>*Sun\ C*)
> # Sun C++ 5.9
Here too. (It only seems to do anything for Sun's C compiler.)
The fewer hunks we have to maintain downstream the better :-)
Richard
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On 12/07/2019 08:49, Richard Sandiford wrote:
Christophe Lyon 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
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 ],
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
...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
Date: Fri, 4 May 2018 15:11:35 +
Subject: [ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpic
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Christophe Lyon writes: > On Fri, 12 Jul 2019 at 08:49, Richard Sandiford > wrote: >> >> Christophe Lyon 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 >> > >> > 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. > > Yes, this was raised by Joseph when I first posted this patch series last > year: > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01507.html > I sent a patch there: > https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html > but didn't get any feedback :-( Ah, OK. In that case, it might be worth adding a comment to libtool.m4 that this has been submitted to libtool but not (yet?) accepted, so at the moment it's a GCC-local change. That might help the next person applying libtool patches to understand the history. >> > 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? > > So.. Let me bring back a bit of history/context. When we developed > FDPIC support in ST several years ago, we used arm-linux-uclibceabi as > triplet. > But when I posted the binutils patch series, Joseph said it wasn't > appropriate and suggested arm-*-uclinuxfdpiceabi instead. > https://sourceware.org/ml/binutils/2018-03/msg00324.html > > This had an impact on the GCC side, because some parts weren't enabled > anymore after the triplet change, so I had to introduce this > configure* patch to restore the missing features. > > Then, I wondered about the impact on other uclinux targets, but it was > hard to find a supported-supposed-to-work one. > I asked for help on the gcc list > (https://gcc.gnu.org/ml/gcc/2018-10/msg00154.html), and finally > managed to build and test an xtensa toolchain. > > And this has an impact on the results on xtensa, as I reported in V3 > of this patch: > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html > > But given the little feedback, I'm wondering whether uclinux targets > are actually still alive/maintained? Well, maybe not maintained :-) But while supporting -shared is AIUI the main goal of FDPIC, I'd be surprised if it was the right thing to test for all uclinux targets. Testing *-*-uclinuxfdpic* would be more obvious IMO. (But there again, I'm not an expert on this stuff.) Thanks, Richard
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
On Fri, 12 Jul 2019 at 08:49, Richard Sandiford
wrote:
>
> Christophe Lyon 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
> >
> > 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.
Yes, this was raised by Joseph when I first posted this patch series last year:
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01507.html
I sent a patch there:
https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html
but didn't get any feedback :-(
>
> > [...]
> >
> > 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?
So.. Let me bring back a bit of history/context. When we developed
FDPIC support in ST several years ago, we used arm-linux-uclibceabi as
triplet.
But when I posted the binutils patch series, Joseph said it wasn't
appropriate and suggested arm-*-uclinuxfdpiceabi instead.
https://sourceware.org/ml/binutils/2018-03/msg00324.html
This had an impact on the GCC side, because some parts weren't enabled
anymore after the triplet change, so I had to introduce this
configure* patch to restore the missing features.
Then, I wondered about the impact on other uclinux targets, but it was
hard to find a supported-supposed-to-work one.
I asked for help on the gcc list
(https://gcc.gnu.org/ml/gcc/2018-10/msg00154.html), and finally
managed to build and test an xtensa toolchain.
And this has an impact on the results on xtensa, as I reported in V3
of this patch:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html
But given the little feedback, I'm wondering whether uclinux targets
are actually still alive/maintained?
>
> > 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...
>
> > @@ -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 ],
>
> is this the right thing to do? It seems odd to be testing the glibc
> version for uclibc.
As said above, I needed to set ac_has_nanosleep and ac_has_sched_yield so that
tests continue to pass after the triplet change. Looks like I got the
effect I wanted, but
not in the right way indeed.
> 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
Right, I think it could be hardcoded.
>
> > @@ -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*)
>
Re: [ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
Christophe Lyon 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
>
> 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.
> [...]
>
> 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?
> 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...
> @@ -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 ],
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
...this redundant.
> @@ -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.
> @@ -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 :-)
Thanks,
Richard
[ARM/FDPIC v5 02/21] [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
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
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*.
Change-Id: I6a1fdcd9847d8a82179a214612a3474c1f492916
diff --git a/config/futex.m4 b/config/futex.m4
index e95144d..4dffe15 100644
--- a/config/futex.m4
+++ b/config/futex.m4
@@ -9,7 +9,7 @@ AC_DEFUN([GCC_LINUX_FUTEX],[dnl
GCC_ENABLE(linux-futex,default, ,[use the Linux futex system call],
permit yes|no|default)
case "$target" in
- *-linux*)
+ *-linux* | *-uclinux*)
case "$enable_linux_futex" in
default)
# If headers don't have gettid/futex syscalls definition, then
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
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c7a464c..67780fb 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -776,7 +776,7 @@ case ${target} in
*-*-fuchsia*)
native_system_header_dir=/include
;;
-*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu)
+*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
extra_options="$extra_options gnu-user.opt"
gas=yes
gnu_ld=yes
@@ -785,7 +785,7 @@ case ${target} in
esac
tmake_file="t-slibgcc"
case $target in
-*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
+*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu |
*-*-uclinuxfdpiceabi)
:;;
*-*-gnu*)
native_system_header_dir=/include
@@ -805,7 +805,7 @@ case ${target} in
*-*-*android*)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_BIONIC"
;;
-*-*-*uclibc*)
+*-*-*uclibc* | *-*-uclinuxfdpiceabi)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_UCLIBC"
;;
*-*-*musl*)
@@ -1167,7 +1167,7 @@ arm*-*-netbsdelf*)
tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
;;
-arm*-*-linux-*)# ARM GNU/Linux with ELF
+arm*-*-linux-* | arm*-*-uclinuxfdpiceabi) # ARM GNU/Linux
with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
extra_options="${extra_options} linux-android.opt"
case $target in
diff --git a/libatomic/configure b/libatomic/configure
index e7076a0..10b0287 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -6055,7 +6055,7 @@ irix5* | irix6* | nonstopux*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
lt_cv_deplibs_check_method=pass_all
;;
@@ -8540,7 +8540,7 @@ $as_echo_n "checking for $compiler option to produce
PIC... " >&6; }
lt_prog_compiler_static='-non_shared'
;;
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
case $cc_basename in
# old Intel for x86_64 which still supported -KPIC.
ecc*)
@@ -9135,7 +9135,7 @@ _LT_EOF
archive_expsym_cmds='sed "s,^,_," $export_symbols
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
-gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdp
