bug#27810: NS runtime feature detection

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

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?