[vlc-devel] [PATCH v2 13/17] contrib: use makefile instead of environment variable

Rémi Denis-Courmont remi at remlab.net
Fri May 1 23:00:32 CEST 2020

That's a very protracted way of stating that, exactly as I had noted, and contrary to your BS claims, autoconf checks symbols just like Cmake and ad-hoc systems do. And all of them have the option of testing code instead, and there is absolutely no autoconf-specific problem here.

And as I noted and as you refuse to admit, under ascending compatibility, switching from symbol to code checks can only fix false negatives, not false positives.

Ascending compatibility is not my opinion. It's an assumption of the build linker (in symbol and library versioning) the compiler (runtime library), pkg-config checks, the vast majority of packages in contribs... And yes Cmake, Meson, autoconf and custom scripts too. Contribs was designed under the same assumption because that is the only viable option when basically everything under it does.

You don't have to like it, and my personal opinion is that it's annoying yet pragmatic. However your cognitive dissonance is not an excuse for denying the fact that contribs work the way they do, even if you doesn't suit you.

Le 1 mai 2020 23:14:35 GMT+03:00, Marvin Scholz <epirat07 at gmail.com> a écrit :
>On 1 May 2020, at 21:49, Rémi Denis-Courmont wrote:
>> Le perjantaina 1. toukokuuta 2020, 22.23.54 EEST Marvin Scholz a 
>> écrit :
>>> On 1 May 2020, at 21:19, Rémi Denis-Courmont wrote:
>>>> Le perjantaina 1. toukokuuta 2020, 21.13.14 EEST Marvin Scholz a 
>>>> écrit :
>>>>> The whole purpose of these hacks, as I already explained, is to
>>>>> workaround the incorrect way autoconf does the checks. So of
>>>>> it is
>>>>> specific to autoconf.
>>>> There is nothing incorrect about autoconf *there* and nothing 
>>>> specific to
>>>> autoconf either. If you ask autoconf to check for a symbol, it does
>>>> so.
>>>> The
>>>> same is true of cmake or of bespoke configure scripts.
>>> Yes there is, I already explained it, I won't repeat myself over and
>>> over
>>> again just because you refuse to read and understand what I write…
>> What mail do I refuse to read?
>Re: [vlc-devel] [PATCH v2 13/17] contrib: use makefile instead of 
>environment variable
>Where I explained:
>The issue is that those checks need to be overwritten with these
>env variables, else configure will get incorrect results, because the
>autoconf check for function existence is fundamentally flawed with
>how it was designed to work. So it can not work for any cases where
>the function declaration provides crucial information for the linker,
>as autoconf will do the check without the right headers included.
>So it makes autoconf come to a wrong result whether it can successfully
>link or not, as it lacks the header with the right annotations for
>weak linking.
>So because this is a somewhat confusing topic I will detail it again
>and what the issue is (will do it for macOS, it's essentially the same
>for iOS, tvOS…):
>For macOS we have a specific minimum macOS version we target (10.11),
>the way this works is by setting the -mmacosx-version-min=10.11
>flags which internally among other things sets a specific define which
>is used by the macOS SDK to know which symbols can be unconditionally
>used (all that are available on 10.11 and higher) and which need weak
>linking (all that are not available since 10.11 but were introduced
>There are basically two ways apps are supposed to handle this:
>If apps are written with awareness to this, the should check if the
>symbol is NULL at runtime, before using it. If it is, run the fallback
>code that does not use the symbol, else just use it.
>For programs that are not aware of this or do not want to deal with
>this, they usually have checks in configure scripts, meson, CMake.
>For these checks to behave right, add -no_weak_imports to the linker
>flags when doing the checks which would cause these to behave like
>they should, as stated in the manage for the flag:
>   Error if any symbols are weak imports (i.e. allowed to be unresolved
>  (NULL) at runtime). Useful for config based projects that assume they
>   are built and run on the same OS version.
>This would work just fine but unfortunately autoconf designed the 
>check macros in a way that you can not easily include the right header
>where the function is actually declared in, so it will lack the correct
>weak annotation and the check will incorrectly succeed.
>This does not only cause problems on macOS, but for Android and Windows
>when doing function existence checks too.
>CMake has CheckFunctionExists which has the same flaw so they
>CheckSymbolExists where they addressed this.
>Mesons function checks supports checking with the right header too and 
>the recommended way to do it.
>So both for CMake and Meson this is a simple to fix issue if any
>runs into this case, just autoconf has no easy fix other than write
>completely custom test program and try to compile that…
>So we have this large hardcoded list as a hack to workaround this with
>autoconf (and because there are a huge number of contribs using
>that run into this issue).
>>>> Sometimes, checking for symbols is wrong because a function or 
>>>> functional
>>>> macro is not guaranteed to exists under the same name as a symbol. 
>>>> In that
>>>> case, a proper code snippet compilation test is necessary. But 
>>>> failing
>>>> that can only ever lead to false negatives, not false positives.
>>> No, you are wrong there.
>> No, you are.
>>>> What's incorrect is the way you're building packages with automatic
>>>> configuration (using autotools or otherwise). You are literaly not
>>>> building
>>>> those the way they're supposed to be built.
>>> No, your assumptions how things should be done are wrong, when 
>>> compiling
>>> with macOS / iOS SDKs and doing specific version targeting.
>> No those are not my assumptions and I already explained it.
>Yes they are because they do not match how things are actually done,
>see my explanation above.
>> Patch rejected.
>> -- 
>> Реми Дёни-Курмон
>> http://www.remlab.net/
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200502/921e5cc6/attachment.html>

More information about the vlc-devel mailing list