bug#27810: NS runtime feature detection

[Charles A. Roelli]

On 06/08/2017 23:29, Alan Third wrote:
> > New scroll styles in 10.7+:
> >
> > +enum {
> > +    NSScrollerStyleLegacy = 0,
> > +    NSScrollerStyleOverlay = 1
> > +};
> > +typedef NSInteger NSScrollerStyle;
> I believe we can make this slightly neater:
>
>      enum NSScrollerStyle {
>        NSScrollerStyleLegacy = 0,
>        NSScrollerStyleOverlay = 1
>      };

Strange, it doesn't work here:

> nsterm.h:58: error: expected ‘)’ before ‘NSScrollerStyle’

> > Add-on to the class declaration of NSScroller (not sure if this is the
> > right way to do it).  Otherwise the compiler errors out on compiling
> > the 10.7+ call to scrollerWidthForControlSize:
> >
> > +@interface NSScroller(NSObject)
> > ++ (CGFloat)scrollerWidthForControlSize:(NSControlSize)controlSize
> > scrollerStyle:(NSScrollerStyle)scrollerStyle;
> > +@end
> Strange... Are you sure this one was an error and not just a warning?
> We’re expecting warnings for this type of thing.

Without it, I get this:

> nsterm.m: In function ‘+[EmacsScroller scrollerWidth]’:
> nsterm.m:8387: warning: ‘NSScroller’ may not respond to 
‘+scrollerWidthForControlSize:scrollerStyle:’
> nsterm.m:8387: error: incompatible types in assignment

I think the compiler has to verify somehow that the result of the call 
is a CGFloat.
Casting to CGFloat gives:

> nsterm.m:8387: error: pointer value used where a floating point value 
was expected

> > Forward declarations for functions used by macfont.m (declared as weak
> > imports since they won't all be available unless we're on 10.8+):
> >
> > +void CTFontDrawGlyphs(CTFontRef font, const CGGlyph *glyphs, const CGPoint
> > *positions, size_t count, CGContextRef context)
> > __attribute__((weak_import));
> > +#endif
> > +
> > +#if !defined (MAC_OS_X_VERSION_10_8) && MAC_OS_X_VERSION_MAX_ALLOWED >=
> > 1080
> > +extern CFArrayRef CTFontCopyDefaultCascadeListForLanguages(CTFontRef font,
> > CFArrayRef languagePrefList) __attribute__((weak_import));
> >
> > The compiler issued no complaints here, but the linker would not link
> > temacs unless the symbols were listed as permitted to be undefined,
> > using this in src/Makefile:
> >
> > ## System-specific LDFLAGS.
> > LD_SWITCH_SYSTEM= -Wl,-U,_CTFontCopyDefaultCascadeListForLanguages
> > -Wl,-U,_CTFontDrawGlyphs
> 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.


> > If they look okay, could you please integrate these changes into your
> > patch?  Thanks a lot for your help on this.
> If you can confirm the scrollerWidthForControlSize thing, I’ll
> incorporate everything else.
>
> Thank you for your help.
>
> Oh, by the way, are you able to check whether the .app built on 10.6
> actually runs on something higher?

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?

By the libraries Emacs depends on, I mean the ones starting with $HOME here:

$ otool -L src/emacs
src/emacs:
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1038.36.0)
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
    $HOME/Build/SnowLeopard/lib/libjpeg.9.dylib (compatibility version 
12.0.0, current version 12.0.0)
    $HOME/Build/SnowLeopard/lib/librsvg-2.2.dylib (compatibility 
version 43.0.0, current version 43.16.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 125.2.11)
    $HOME/Build/SnowLeopard/lib/libgio-2.0.0.dylib (compatibility 
version 4503.0.0, current version 4503.0.0)
    $HOME/Build/SnowLeopard/lib/libgdk_pixbuf-2.0.0.dylib 
(compatibility version 3401.0.0, current version 3401.0.0)
    $HOME/Build/SnowLeopard/lib/libgobject-2.0.0.dylib (compatibility 
version 4503.0.0, current version 4503.0.0)
    $HOME/Build/SnowLeopard/lib/libglib-2.0.0.dylib (compatibility 
version 4503.0.0, current version 4503.0.0)
    $HOME/Build/SnowLeopard/lib/libintl.9.dylib (compatibility version 
11.0.0, current version 11.4.0)
    $HOME/Build/SnowLeopard/lib/libcairo.2.dylib (compatibility version 
11403.0.0, current version 11403.6.0)
    $HOME/Build/SnowLeopard/lib/libxml2.2.dylib (compatibility version 
12.0.0, current version 12.4.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current 
version 5.4.0)
    $HOME/Build/SnowLeopard/lib/libgnutls.30.dylib (compatibility 
version 40.0.0, current version 40.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.3)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current 
version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 550.44.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 
(compatibility version 1.0.0, current version 38.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 751.63.0)

Do either of these sound feasible?