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 11D3F402BF for ; Thu, 21 Jul 2022 20:47:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 67DDC68B53C; Thu, 21 Jul 2022 23:47:41 +0300 (EEST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E216E68B41C for ; Thu, 21 Jul 2022 23:47:34 +0300 (EEST) Received: by mail-wr1-f52.google.com with SMTP id z13so3889998wro.13 for ; Thu, 21 Jul 2022 13:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=2wRGjP/dXp78Eo1MEhuvlXobHxe4LqEXBw+PrltTiJk=; b=5g4p+f9b8N4Ksdz2J0ESZs0Nyo5dVmQvv9BL+fYVb1TAExRYmPaPkaQmUtxtjgm3lJ iWK/tMQtZHgtxhBr3b+BFmpMKC/KGr7tLc3rU5UkDrZ+2OVTPYKrnOMXIxV8cb3yYlX/ wDi+C9CIOJAUny8/gJWT88COCZdZuOroFK4vDtyMZIULGWdO/7g6ZHfQkzVALCk38d0W UusMjVSkge0hzJVvgbnQCJyqJQSmMapsMNMksNAgaM/4xwswe7/ymZS3CmaKHwKKSPdJ JcU7TrkoNs7TtCma+Zs/BNEG69zigaIVsxagGqYyflY3c2WWCEbm+SLVw2SubaPEpOqr pSDw== 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=2wRGjP/dXp78Eo1MEhuvlXobHxe4LqEXBw+PrltTiJk=; b=2639hgRhj6Qf0cRCmY9Qf+ZVrAfncKbulNUB5ixKiZEVzUKmd6Y1jSPnHbAUC92E5A J+U3p3Ve60+n4iy7A+O0yNagB49Vwtf/YOdLT2GEqp2ItfTG7OOlyhCjPj9XrgHDVxhf 5EqX2mxCreapcwcNNuNdaVFfd8gCFLWEqHksbnwObzl3+VHLjkGw7/kxV1hAQfLAF+BG 7aYzdC1v5EaNOLOicSZlmkbP2AYtyedWtZixEGWpK7YHEks7QF98xFZFtAavEcAYuSLi IM8NCNAq5oZu1uSRhN2ge2FzkGZlFw7nJZORvWRuwxullomhgpZpHxKZo0EDO0Sn8Glj rg/g== X-Gm-Message-State: AJIora95PQR2yJp17tHJ0EXomx6igM8x7kXalPEx1cu0CW4WAtkw8+1D PIYQqMRbSReETR88uIRzWBGjoxVzQYDaSA== X-Google-Smtp-Source: AGRyM1szeNQv4cIO5oKiA3DAScXghZQH7Ax5bRQ29GpJKueAtbTThHKvS+fNpLFpkY7DyIcHWA7/ew== X-Received: by 2002:a05:6000:1b0e:b0:21e:3553:3e73 with SMTP id f14-20020a0560001b0e00b0021e35533e73mr178242wrz.144.1658436453256; Thu, 21 Jul 2022 13:47:33 -0700 (PDT) Received: from [192.168.0.14] (cpc91224-cmbg18-2-0-cust209.5-4.cable.virginm.net. [81.106.228.210]) by smtp.gmail.com with ESMTPSA id q12-20020adff50c000000b0021e5757fb4csm2128133wro.88.2022.07.21.13.47.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jul 2022 13:47:32 -0700 (PDT) Message-ID: Date: Thu, 21 Jul 2022 21:47:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220719175310.647621-1-emil.l.velikov@gmail.com> From: Mark Thompson In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] hwcontext_vaapi: dlopen libva-x11 and libva-drm 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 20/07/2022 17:41, Emil Velikov wrote: > On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote: >> >> Emil Velikov (12022-07-19): >>> As you may know the libva* set of libraries share an internal ABI >>> between them. In a resent libva commit, the va_fool API was removed. >>> >>> Thus if one is to mix different versions of libva.so and libva-x11.so >>> they will get an error, leading to a crash of the whole stack. >>> >>> The simple solution is >> >> ... a configure check. >> >> If the person who installs replaces a library with another, it is their >> responsibility to check they are compatible. >> > > While I wholeheartedly agree, it's not so easy to enforce compile time > decisions at runtime. In the past, I have debugged and reported issues > where Linux distributions do not enforce the above. > > We do have the typical Linux distribution model (where we have dozens > upon distros) and other distribution models. IMHO checking each > instance and combination doesn't scale. We could bring awareness to > the issue in say distribution/workflow X, which sadly may come as > finger-pointing and thus alienating. > > Hope that makes sense and the team is willing to consider the extra 90 > lines worth of code. The argument "libfoo can be broken in some particular configuration, so lets use dlopen() to make errors happen later" seems like it applies to every library. Why is this case so special? Who are the users running into this specific problem and who are stuck with broken versions they can't update? (Also, shouldn't lazy binding save people in this situation if they don't actually use the feature, as they presumably don't if barfing at runtime makes sense?) Tbh I don't think FFmpeg libraries are the right place to be putting this sort of workaround. Thanks, - Mark _______________________________________________ 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".