bug#27810: NS runtime feature detection

[Charles A. Roelli]

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

remove-forward-compatibility-changes.diff
Description: application/diff