From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id EC7054026C for ; Wed, 19 Jan 2022 13:16:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6C4E368B01B; Wed, 19 Jan 2022 15:16:27 +0200 (EET) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0BCEF68AF9C for ; Wed, 19 Jan 2022 15:16:21 +0200 (EET) Received: by mail-oi1-f176.google.com with SMTP id s127so4072231oig.2 for ; Wed, 19 Jan 2022 05:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=SFNoHEDBZD365js3pZKqewAspyaWBMEZHA/IBeUuWtM=; b=a570HugO74lad+coMpgQrtLcYG5c6ne32dz4r+3EwDexxG1Gzsx29dvpJ/+KRGSjeX 1gLIQ4Nzv1V16rFzXZuA7x9ecpQUWAzQWAWsbcSzaRPqJNfupF+iZ/1R1M0gxkHEU8Ie J6R4fAWKm2yre1Y9WBGjgQZN0EgRYlZJUR44K5VaUQJvqYkKKL71o3rdSG3BZWuDWxiN JMx7lgTxkjUw1EfN/Gjyg0XVcIavJV+qjfXZzPCws/n92CrtrP1kD0CzwbGoIA9xdTHO psxYBk59Z9DDWumIuWJ4bBdIYBNeuiH4j4wJPpbTc6ZbA/sLE+zNeFqWm/dO3HYjgWUh L5CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=SFNoHEDBZD365js3pZKqewAspyaWBMEZHA/IBeUuWtM=; b=svRg9AiozAxDjdCg9j9KR/7PIY4xZ/VDOHI5+g2ynWz3v4xvB1b7k/cedPIOqRuKhI i8xhnhgmW39NtiMGdC5IX5jfrbQIPbxIiUYE8pl1+q+ICac0x0rXLaWJ/YV005icq5/E kyGtBMHnvSIW+cWmS1G2Ab09Y/zVGJz+FNzIvTt9KUPG6oIncfoldVrUDx6RjoyY08U9 03vFU+ngkhswx+imc/GJsNbeq2pJSHysYY9X50I52PJYmqr2uQze+wTLTa6XW/zhB/Aw Aa1ExNfuYj4141YR7mJxcDKx7K8Ywj7EiKZ2fjqc0/3+d6eLVG23dIKn45c207kruPtm pXVA== X-Gm-Message-State: AOAM532xGYb/C5J7fBzSRlsrZZLe9d5JIt+mYi/pNDc7pqJNfuXpd0oq vCE3YK5q8RExE0SjbiivA4hPysjGR9I= X-Google-Smtp-Source: ABdhPJxQlpTPWdv8svGQApDXU7/Z1ZJKW47VgP49pE1CL191LZvEzTMifoCYRtbutaK8YOGZA47adg== X-Received: by 2002:aca:ebc5:: with SMTP id j188mr2943021oih.90.1642598178392; Wed, 19 Jan 2022 05:16:18 -0800 (PST) Received: from [192.168.0.13] ([186.136.131.95]) by smtp.gmail.com with ESMTPSA id c15sm8001357ooq.30.2022.01.19.05.16.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jan 2022 05:16:17 -0800 (PST) Message-ID: <3335e1d2-14ee-8e3c-2e81-a6a077f7ee47@gmail.com> Date: Wed, 19 Jan 2022 10:16:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220119115432.12571-1-anton@khirnov.net> <0bd6970d-e2c9-0ff1-3137-5b01dbff3a86@gmail.com> <164259604467.23111.3104146160553486070@lain.red.khirnov.net> From: James Almer In-Reply-To: <164259604467.23111.3104146160553486070@lain.red.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH] configure: link to libatomic when it's present X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 1/19/2022 9:40 AM, Anton Khirnov wrote: > Quoting James Almer (2022-01-19 13:34:20) >> >> >> On 1/19/2022 8:54 AM, Anton Khirnov wrote: >>> C11 atomics in some configurations (e.g. 64bit operations on ppc64 with >>> GCC) require linking to libatomic. >>> --- >>> Testing welcome, especially in configurations where >>> * libatomic is not present >>> * libatomic is actually needed >>> --- >>> configure | 9 ++++++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/configure b/configure >>> index 1413122d87..1ff5dbee5b 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -6324,7 +6324,14 @@ check_headers asm/types.h >>> # it seems there are versions of clang in some distros that try to use the >>> # gcc headers, which explodes for stdatomic >>> # so we also check that atomics actually work here >>> -check_builtin stdatomic stdatomic.h "atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); foo += bar" >>> +# >>> +# some configurations also require linking to libatomic, so try >>> +# both with -latomic and without >>> +for LATOMIC in "-latomic" ""; do >> >> Shouldn't you try without it first? On my toolchain libatomic is >> present, but libraries compile without linking to it just fine. That >> changes after this patch, where it starts linking to it explicitly. > > No, because it may only be needed for some atomic sizes and operations, > which the test in configure doesn't necessarily catch. > And because we pass as-needed to the linker, the built libraries > shouldn't actually require libatomic unless it's really needed. Ah, didn't consider --as-needed. > >> >>> + check_builtin stdatomic stdatomic.h \ >>> + "atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); foo += bar" \ >>> + $LATOMIC && add_extralibs $LATOMIC && break >> >> You should probably add it to the required libraries' extralibs only. >> Just replace the add_extralibs part with setting stdatomic_extralibs to >> $LATOMIC, and then add stdatomic to all the libraries' _suggest lists, >> same as we do for libm. > > Then we need to actively track which libraries actually use atomics, > which also depends on which features are enabled. Given that this only > fails on less-common arches, this sounds like a recipe for obscure build > failures. Given that it's only really linked when needed, it seems > better to just add it unconditionally. Then just add it to all of them, like we do for libm. What i want to avoid is having it in EXTRALIBS. There was a huge configure rework long ago that removed everything from that variable (leaving it as the place where user defined --extra-libs arguments are dumped), and fine tuned ld arguments in a per library/module basis. I'd like to not go back to start dumping everything in EXTRALIBS. Like this, on top of this patch: > diff --git a/configure b/configure > index 1ff5dbee5b..43713a7679 100755 > --- a/configure > +++ b/configure > @@ -3794,20 +3794,20 @@ cws2fws_extralibs="zlib_extralibs" > > # libraries, in any order > avcodec_deps="avutil" > -avcodec_suggest="libm" > +avcodec_suggest="libm stdatomic" > avdevice_deps="avformat avcodec avutil" > -avdevice_suggest="libm" > +avdevice_suggest="libm stdatomic" > avfilter_deps="avutil" > -avfilter_suggest="libm" > +avfilter_suggest="libm stdatomic" > avformat_deps="avcodec avutil" > -avformat_suggest="libm network zlib" > -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt" > +avformat_suggest="libm network stdatomic zlib" > +avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl stdatomic user32 vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt" > postproc_deps="avutil gpl" > -postproc_suggest="libm" > +postproc_suggest="libm stdatomic" > swresample_deps="avutil" > -swresample_suggest="libm libsoxr" > +swresample_suggest="libm libsoxr stdatomic" > swscale_deps="avutil" > -swscale_suggest="libm" > +swscale_suggest="libm stdatomic" > > avcodec_extralibs="pthreads_extralibs iconv_extralibs dxva2_extralibs" > avfilter_extralibs="pthreads_extralibs" > @@ -6330,7 +6330,7 @@ check_headers asm/types.h > for LATOMIC in "-latomic" ""; do > check_builtin stdatomic stdatomic.h \ > "atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); foo += bar" \ > - $LATOMIC && add_extralibs $LATOMIC && break > + $LATOMIC && eval stdatomic_extralibs="\$LATOMIC" && break > done > > check_lib advapi32 "windows.h" RegCloseKey -ladvapi32 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".