bug#27810: NS runtime feature detection

["Charles A. Roelli" <charles@aurox.ch>]

Hm, on second thoughts, it seems a bit overwrought to try doing this
weak linking only for the sake of forward-compatible builds.  It
should be enough to support only backward-compatible builds, so that
we might one day distribute Emacs as a .dmg (built on the latest macOS
and backwards-compatible with the oldest version of macOS that we
support).  I don't want to waste time adding code that will hardly
ever be run, so we can take out those forward declarations.  Sorry for
the trouble!  I will send a patch on top of your new one that removes
them (I'm also having build trouble at the moment).

I also looked at the emacsformacosx.com build scripts, and it seems
like they're making copies of Emacs' dependent dynamic libraries,
including them in the application bundle, then using
install_name_tool(1) to patch the Emacs binary to depend on them (I
don't understand, though, how those scripts resolve dependencies
between the dynamic libraries themselves).


On 10/08/2017 23:04, Alan Third wrote:
> On Mon, Aug 07, 2017 at 09:23:10PM +0200, Charles A. Roelli wrote:
>> On 06/08/2017 23:29, Alan Third wrote:
>>> I believe we can make this slightly neater:
>>>
>>>       enum NSScrollerStyle {
>>>         NSScrollerStyleLegacy = 0,
>>>         NSScrollerStyleOverlay = 1
>>>       };
>> Strange, it doesn't work here:
> We’ll just go with what works, then.
>
>>> I’ve done a bit more reading up on this and I think I’ve misunderstood
>>> how this works, and probably mislead you.
>>>
>>> It seems these functions need to be declared as weak in the definition
>>> of the library they’re supposed to be in. If we declare them in the
>>> Emacs code‐base then the linker, reasonably, expects the functions to
>>> be in the Emacs code‐base.
>> Maybe I'm also confused.  I thought we would be able to do this,
>> since:
>>
>>    - At link time, the symbol is marked as a weak reference, to be
>>      resolved at runtime.
>>
>>    - At runtime, the dynamic linker resolves the reference to the weak
>>      symbol, setting it to NULL if it isn't available.  Normally the
>>      definition of the function will be found in a dynamic library that
>>      is part of macOS (as far as I understand).
>>
>> The Apple compiler/linker should be capable of doing this, supposedly,
>> as long as you give the magical -Wl,-U,_symbol command line arguments
>> to the linker.  See also https://stackoverflow.com/a/34983229.
> That’s quite a good description. I guess that we want to do what
> you’re suggesting, then. I’m not sure how, though. I’ll try to have a
> look through configure.ac to see if I can work it out sometime over
> the weekend.
>
>> I'd like to check, but wouldn't I need to either:
>>
>> a) Statically link libraries Emacs depends on, or
>> b) Include the dependent libraries in the app bundle?
> Yes, I suppose so. I kind of assumed it would statically link at least
> some of them, but I guess not.
>
> I’ve had a look at the build scripts for emacsformacosx.com, but I
> don’t understand what they’re doing.
>
> I’ve attached what I have so far, which I think includes all your
> changes except for the requirements for linker arguments.
> Unfortunately master doesn’t build here now because of some other
> problem so it’s untested.