bug#27810: NS runtime feature detection

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

[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]

(I fixed the build issue with 'make bootstrap')

Attached is the patch to revert my changes.


On 12/08/2017 13:13, Charles A. Roelli wrote:
> 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.
>


[-- Attachment #2: remove-forward-compatibility-changes.diff --]
[-- Type: application/diff, Size: 4320 bytes --]