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

[Christophe Lyon]

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
> .
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ARM-FDPIC-Handle-arm-uclinuxfdpiceabi-in-configure-s.patch
Type: text/x-patch
Size: 12760 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190829/dcf645ce/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0024-ARM-FDPIC-Handle-arm-uclinuxfdpiceabi-in-libstdc-con.patch
Type: text/x-patch
Size: 8710 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190829/dcf645ce/attachment-0001.bin>