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

[Marvin Scholz]

On 1 May 2020, at 23:00, Rémi Denis-Courmont wrote:

> 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.

I just explained very detailed that no, contrary to Cmake and Meson, 
with autoconf you can not properly include
the right header so the check will claim the symbol is usable even 
though it is not usable on the version
we target. This being unfixable trivially is a autoconf specific 
problem.

>
> 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.
>

So how is this any helpful and even relevant to what this patch does, 
which is just moving
the EXISTING workarounds for this around? We DO target the correct 
lowest version we need to support,
it is autoconf that does not manage to offer a way to include the right 
headers, that would cause the
linker checks behave correctly… It's obviously not feasible to enforce 
building contribs with an
ancient SDK as it would make the build process a big mess.

I really have no clue whatsoever what you expect us to do here instead? 
Fix all dependencies instead,
to handle this correctly?

You don't even build for Darwin so why do you even care and review stuff 
you don't really
understand how its done and what workarounds we need… I am tired of 
this and your endless
pointless "discussions" where you refuse to accept any sort of middle 
ground, don't properly
explain your objections and what do you about them and in general refuse 
to be helpful in
any way…

Big news but you are not working on this project alone but together with 
a group of
other people.

Oh and it's unacceptable to say stuff like "[…] apparently some people 
here have reading
disabilities […]". If you are in a bad mood, don't reply to mails and 
do something thats
fun, instead of spreading your frustration around the mailing list and 
being mean to
other people.

> 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
>> course
>>>>>> 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
>> compiler
>> 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
>> later).
>>
>> 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
>> function
>> 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
>> introduced
>> CheckSymbolExists where they addressed this.
>>
>> Mesons function checks supports checking with the right header too 
>> and
>> it's
>> the recommended way to do it.
>>
>> So both for CMake and Meson this is a simple to fix issue if any
>> contrib
>> runs into this case, just autoconf has no easy fix other than write
>> your
>> 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
>> autoconf
>> 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:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez 
> excuser ma brièveté.


> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel