[MPlayer-cvslog] r38197 - trunk/configure

[KO Myung-Hun]

Hi/2.

reimar wrote:
> Author: reimar
> Date: Sun Aug 30 20:44:21 2020
> New Revision: 38197
> 
> Log:
> configure: check that stdatomic.h actually works correctly.
> 
> In particular, that it does not create e.g. dependencies on
> libatomic. In that case the compat fallback will actually work better.
> 
> Modified:
>    trunk/configure
> 
> Modified: trunk/configure
> ==============================================================================
> --- trunk/configure	Sun Aug 30 18:54:24 2020	(r38196)
> +++ trunk/configure	Sun Aug 30 20:44:21 2020	(r38197)
> @@ -3960,7 +3960,9 @@ echores "$_fast_inttypes"
>  
>  echocheck "stdatomic.h"
>  stdatomic_h=no
> -header_check stdatomic.h && stdatomic_h=yes
> +# need to use statement_check because some implementations (Rasbian) create a dependency
> +# on libatomic, in which case we rather want to use the fallback
> +statement_check stdatomic.h "atomic_int_least64_t a; atomic_fetch_add_explicit(&a, 5, memory_order_relaxed)" && stdatomic_h=yes
>  echores "$stdatomic_h"
>  if test "$stdatomic_h" = no ; then
>    CFLAGS="-Icompat/atomics/gcc $CFLAGS"

This breaks OS/2 builds with --enable-runtime-cpudetection using gcc v9.1.

First, the above test fails because -march=i486 is used if
--enable-runtime-cpudetection is used without --target like:

    Undefined symbol ___atomic_fetch_add_8 referenced from text segment

__atomic_fetch_and_add_n builtins are supported on -march=i586 or later.

Second, compat/atomic/gcc/stdatomic.h uses __sync builtins.

However, some __sync builtins are supported on i586 or later, too.

As a result, linkage fails like:

    undefined symbol ___sync_fetch_and_add_8
    undefined symbol ___sync_fetch_and_sub_8


-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v6.1.10 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.os2.kr/