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 1EB16474D0 for ; Fri, 8 Sep 2023 18:58:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 91D7C68C85E; Fri, 8 Sep 2023 21:58:30 +0300 (EEST) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2581F68C7FE for ; Fri, 8 Sep 2023 21:58:23 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 990F41770D3 for ; Fri, 8 Sep 2023 20:58:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1694199500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=//lLQ6l62Tca2XaWdwJDLZ1S3K6SlVlSAJg+pW3mCXQ=; b=X8LixZkDPapYpxhuQHoY3zIDrHn6k06vQLmXQWN2jmtppfQ6Aha9A61i1jQcg57MO/jq4T nqVK43np9r5VEDnQ4TrCZ2Zg2eLh8tO8xRZWWV0Cb1hHm+UO3DIkGjiFGG3/Cs5aM8Tv6u wv+0H6ihZT8KtyyIEfGxQH4b1N4OdVq+FgJcimM8DRHYexQ5P6mTiyGV9mteAOMTxDOSF7 VS0yokNw6ahxbQHfAFh/bq5lR/GIxfV1RrTBlgg4o4yGs0yfiOn53/Xlet974KdvL+cEV7 3fkqppnpWz40qSAe649iub6EY8EfDzheqEpEJvaIfI6W9DsZfrDOMn5hoAahrQ== Message-ID: Date: Fri, 8 Sep 2023 20:58:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: ffmpeg-devel@ffmpeg.org References: <20230905232630.2031-1-kasper93@gmail.com> <32b7a66e-1b20-6912-6a2b-993821cd470c@rothenpieler.org> <2f980e77-31cb-64ae-d172-28f5cc498b3d@rothenpieler.org> Content-Language: en-US From: Timo Rothenpieler In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] configure: don't force specific C++ standard library linking 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 08.09.2023 20:55, Kacper Michajlow wrote: > On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel > wrote: >> >> On 07.09.2023 23:38, Kacper Michajlow wrote: >>> On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis >>> wrote: >>>> >>>> On 9/6/2023 6:31 PM, Kacper Michajlow wrote: >>>>> What would be a downside of preferring CXX always if it exists? >>>> >>>> FFmpeg runs in a multitude of environments with a multitude of portability >>>> requirements. Needlessly linking a C++ runtime is not OK. >>> >>> This does not answer my question. Let me rephrase. Do we know the case >>> where using C++ compiler driver rather than C would degrade the >>> quality of the resulting build? >>> >>> Using C++ driver would indeed append the (correct) runtime library to >>> the linker command, but if nothing references any symbols from it it >>> would not be linked. It is also why the current way of forcing >>> `lstdc++` kinda works, because it is silently ignored when not needed. >>> >>> Implementing logic to use C++ only when necessary is possible, but I'm >>> not a big fan of such automation. And in practice not sure how well it >>> would work, because it would require trying to link twice every >>> dependency in configure. >>> >>> Also the fact that "FFmpeg runs in a multitude of environment" is >>> precisely why I really don't like the current unconditional including >>> `-lstdc++`. >> >> Couldn't you just check if stdc++ is in the ldflags/extralibs, and if >> so, remove it, and use g++ to link? > > Well, I'm lost now. Are you suggesting building on top of existing > hacks is a better solution than the proposed patch? The proposed patch looks like a near unmaintainable hack to me as it is. Anything that's less brittle is highly preferred. There is no good solution here, but I'm very much against any solution that has high potential for random breakages and hard to predict side-effects. > I refuse supporting any kind of random `-lstdc++` adding in configure > and then removing it in the end. > > - Kacper _______________________________________________ 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".