erkkah / tigr

TIGR - the TIny GRaphics library for Windows, macOS, Linux, iOS and Android.
Other
745 stars 44 forks source link

Does not build on macOS Big Sur (11.5) #24

Closed amatzko closed 2 years ago

amatzko commented 3 years ago

Error: src/tigr.c:2744:18: error: no matching function for call to 'objc_msgSend'

It looks like they changed the function signature for objc_msgSend, but it's deprecated anyway. Any idea how to fix this?

erkkah commented 3 years ago

Hi. It might be the Known issue that you need to define OBJC_OLD_DISPATCH_PROTOTYPES to build. Have you tried that?

amatzko commented 3 years ago

Thanks, that fixed it. Unfortunately, now the application crashes due SecTaskLoadEntitlements. We’re compiling with gcc and don’t have an Info.plist, so that’s probably the issue?

jjmarchewitz commented 3 years ago

Hi, I am working with @amatzko, and for me defining OBJC_OLD_DISPATCH_PROTOTYPES didn't work, at least with values of 0 and 1 when I defined it inside of game.cpp, or inside of tigr.c. Here's the whole output if that helps:

g++ -I./src -MMD -MP -DOBJC_OLD_DISPATCH_PROTOTYPES -c -o src/tigr.o src/tigr.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated] src/tigr.c:3203:12: error: no matching function for call to 'objc_msgSend' id wdg = objc_msgSend(window, sel_registerName("delegate")); ^~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/objc/message.h:63:1: note: candidate function not viable: requires 0 arguments, but 2 were provided objc_msgSend(void / id self, SEL op, ... / ) ^ 1 error generated. make: *** [src/tigr.o] Error 1

erkkah commented 3 years ago

Hi. Are you on M1 by any chance? I have fixes for arm in the mac-arm branch, which will be ready for release soon.

jjmarchewitz commented 3 years ago

I am, I have been wondering if that would be the cause. Thank you for the update and the hard work!

erkkah commented 3 years ago

Should be fixed now in 2.1 (#25).

amatzko commented 2 years ago

@erkkah thanks for the fix & merge. Do you have any examples of a working Tigr project on Mac? On both on M1 and Intel devices, we are getting a SecTaskLoadEntitlements crash on startup.

Here is a stacktrace:

2021-09-20 16:18:47.382612-0400 game[46798:177607] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=46798
2021-09-20 16:18:47.382724-0400 game[46798:177607] SecTaskCopyDebugDescription: game[46798]/0#-1 LF=0
Process 46798 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x44)
    frame #0: 0x00007fff201cfdab libobjc.A.dylib`class_conformsToProtocol + 317
libobjc.A.dylib`class_conformsToProtocol:
->  0x7fff201cfdab <+317>: testl  %eax, 0x44(%rbx)
    0x7fff201cfdae <+320>: jne    0x7fff201cfdc4            ; <+342>
    0x7fff201cfdb0 <+322>: movq   0x8(%rbx), %rdi
    0x7fff201cfdb4 <+326>: callq  0x7fff201c8bca            ; getProtocol(char const*)

Seems like the crash is in tigrUpdate, specifically around line 3260.

amatzko commented 2 years ago

Here's a better stacktrace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                 0x00007fff201cfdab class_conformsToProtocol + 317
1   libobjc.A.dylib                 0x00007fff201cfc52 -[NSObject conformsToProtocol:] + 47
2   com.apple.AppKit                0x00007fff232d2dd6 -[NSApplication(NSTouchBarFinder) NS_touchBarProviders] + 401
3   com.apple.AppKit                0x00007fff232d3f7f _NSTouchBarFinderGatherProvidersForContainer + 64
4   com.apple.AppKit                0x00007fff232d40b1 _NSTouchBarFinderGatherProvidersForContainer + 370
5   com.apple.AppKit                0x00007fff232d40b1 _NSTouchBarFinderGatherProvidersForContainer + 370
6   com.apple.AppKit                0x00007fff232d3608 ___NSTouchBarFinderSetNeedsUpdateOnMain_block_invoke_2 + 535
7   com.apple.AppKit                0x00007fff22cffea5 NSDisplayCycleObserverInvoke + 155
8   com.apple.AppKit                0x00007fff22cffa30 NSDisplayCycleFlush + 953
9   com.apple.QuartzCore            0x00007fff26b95c86 CA::Transaction::run_commit_handlers(CATransactionPhase) + 92
10  com.apple.QuartzCore            0x00007fff26b94a1d CA::Transaction::commit() + 375
11  com.apple.AppKit                0x00007fff22daf86c __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 285
12  com.apple.AppKit                0x00007fff23505332 ___NSRunLoopObserverCreateWithHandler_block_invoke + 41
13  com.apple.CoreFoundation        0x00007fff20424d01 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
14  com.apple.CoreFoundation        0x00007fff20424b95 __CFRunLoopDoObservers + 543
15  com.apple.CoreFoundation        0x00007fff20424028 __CFRunLoopRun + 841
16  com.apple.CoreFoundation        0x00007fff2042361c CFRunLoopRunSpecific + 563
17  com.apple.HIToolbox             0x00007fff28669a83 RunCurrentEventLoopInMode + 292
18  com.apple.HIToolbox             0x00007fff286696b6 ReceiveNextEventCommon + 284
19  com.apple.HIToolbox             0x00007fff28669583 _BlockUntilNextEventMatchingListInModeWithFilter + 70
20  com.apple.AppKit                0x00007fff22c2b172 _DPSNextEvent + 864
21  com.apple.AppKit                0x00007fff22c29945 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1364
22  XXX     0x0000000107a6671c tigrUpdate + 364
23  XXX     0x0000000107a68ea4 main + 196
24  libdyld.dylib                   0x00007fff20347f3d start + 1
amatzko commented 2 years ago

Sorry for the spam... using this github answer I was able to find the solution, by commenting out this line: bool resultAddProtoc = class_addProtocol(appDelegateClass, objc_getProtocol("NSApplicationDelegate"));

erkkah commented 2 years ago

Thanks for the continued reporting, @amatzko. Yes, everything works fine on my end, on both intel and M1, so I'm really grateful for your testing. Do both your macs have touchbars? Does this happen when you build the example projects?

tips48 commented 2 years ago

Both our macs have touchbars. This happens when we build the example project. We've been using the fix I posted in the last comment and have not noticed any side effects so far.

erkkah commented 2 years ago

Cool, thanks, that makes sense. I'll push the fix soon.

tips48 commented 2 years ago

@erkkah In other weird news, I had to #include <stddef.h> under #ifdef _WIN32 in order to build with mingw32 (gcc) on Windows 10.

amatzko commented 2 years ago

Apologizes - was posting from a different account.

erkkah commented 2 years ago

Thanks again for reporting. I haven't seen that on my end. Will fix.

erkkah commented 2 years ago

These issues should be fixed by PR #26, thanks again for reporting!

RechieKho commented 9 months ago

Still not working for me, the error on line 2947 in debug mode. It fails even after I define the macro mentioned.

static void _showPools(const char* context) {
    fprintf(stderr, "NSAutoreleasePool@%s:\n", context);
    objc_msgSend(class("NSAutoreleasePool"), sel("showPools"));
}

Through this stack overflow answer

The compilation succeeds as I change to this:

static void _showPools(const char* context) {
    fprintf(stderr, "NSAutoreleasePool@%s:\n", context);
    ((id (*)(id, SEL))objc_msgSend)(class("NSAutoreleasePool"), sel("showPools"));
}

In other objc_msgSend, you add the same prefix, but not in _showPools.

    id window = ((id(*)(id, SEL, NSRect, NSUInteger, NSUInteger, BOOL))objc_msgSend)(
        windowAlloc, sel("initWithContentRect:styleMask:backing:defer:"), rect, windowStyleMask, 2, NO);

I guess you missed something?

I'm compiling the library on MacBook Pro Apple M2 Ventura.