[vlc-devel] [PATCH v2 13/17] contrib: use makefile instead of environment variable
epirat07 at gmail.com
Fri May 1 22:14:35 CEST 2020
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
>>> same is true of cmake or of bespoke configure scripts.
>> Yes there is, I already explained it, I won't repeat myself over and
>> 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
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
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
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 introduced
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 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
>>> 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
>>> 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
>>> those the way they're supposed to be built.
>> No, your assumptions how things should be done are wrong, when
>> 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.
> Реми Дёни-Курмон
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel