I think I found a bug in the Objective-C++ compiler, linker, or runtime. Here’s the scenario: We have a macOS app written in Swift. To control hardware from a 3rd party manufacturer, we use a couple SDKs provided by the manufacturer. The SDKs use dynamically loaded libraries and the interface is defined in C++ headers. To bridge between our Swift code and the C++ APIs we have a private Cocoapod that wraps the 3rd party interface with Objective-C++ classes. The two SDKs each provide an interface for discovering attached devices using a callback class that the programmer provides. By accident we named both callback implementations DiscoveryCallback, but this was not a compiler error because neither class was publicly declared, and each was defined in the .mm file where it was used. However, the problem we’re seeing is this: We want to discover Videohub devices, so we register a new instance of DiscoveryCallback (defined in the same .mm file as this code) with the Videohub SDK. A Videohub device is connected and the SDK calls a method on our callback. Surprise! The callback we registered in step 1 was actually the one intended for Decklink devices, defined in a completely different .mm file. This violates all sorts of assumptions and our app quickly crashes. The funny thing is, the two implementations of DiscoveryCallback have completely different method names. The Videohub SDK is supposed to be calling NewVideohubDevice, yet somehow it successfully calls DeckLinkDeviceArrived on an instance of a class it shouldn’t even know about. So the compiler has checked that our intended DiscoveryCallback matches the protocol that the SDK expects, but at runtime the compiled code instantiates a completely different implementation of DiscoveryCallback and somehow doesn’t immediately fail; we still call a method on it that doesn’t even share a name with the intended target. I imagine at this point the method names are long forgotten and are just pointers in a table. I don’t know if this is a bug in the compiler, the Objective-C++ runtime, or if this is just “working as designed” undefined behavior that I should have avoided by not giving two private classes the same name. I know it’s possible to use a private API simply by redeclaring it in my own code, and this seems related to that, but I feel like the compiler or linker should have warned me that I had two implementations of the same class, or if that is not an error, then the runtime should have instantiated the class that was privately defined in the same source file where it was used. Obviously I can’t share our entire project; I’d like to provide some sample code that replicates the issue, but I don’t have time to do that right now. I’m posting this to see if other developers have had a similar experience.

I am getting an following error while compiling the Fortran file with "gfortran TEST_1_fortran_only_fixed.f" ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libSystem.tbd' for architecture x86_64 collect2: error: ld returned 1 exit status Please help me to solve this issue

I'm the developer of 8th (https://8th-dev.com), which compiles the program at run-time, on the device. There used to be an iOS version which worked, but it seems things have changed since then. I'm trying to distribute an iOS version of an app written in 8th, and am encountering "SIGKILL - CODESIGNING" when trying to execute freshly compiled code. I am doing the 'sys_icache_invalidate' thing after writing into a mmap'ed bit of memory (rwx). I'm not writing into memory that was codesigned, so I don't know why the error is that. Anyway, the question is: is it possible any more to do what I used to be able to do?

Hi, I am writing my own little toy programming language and when I try to link the binary object file (.o file) it requires a _main symbol. I wonder if there is a way to exclude this, presumably, a C runtime requirement? Is it safe to provide a stub _main symbol, or provide a the _main as the entry point to my own little runtime? What is the correct way to invoke the linker with the appropriate flags?

In a completely new project using Objective-C, when using "NSDateFormatter" under the conditions mentioned, setting initWithLocaleIdentifier to "NSCalendarIdentifierGregorian" results in "dateFromString" returning nil. This issue is occurring specifically in iOS 18 beta 1 and 2, and it's causing me significant trouble. This process works correctly on iOS 17 and earlier versions. NSDateFormatter *formatter = [[NSDateFormatter alloc] init]; [formatter setTimeStyle:NSDateFormatterFullStyle]; [formatter setLocale:[[NSLocale alloc] initWithLocaleIdentifier:NSCalendarIdentifierGregorian]]; [formatter setDateFormat:formatStr]; NSDate *date = [formatter dateFromString:formatStr]; "date" is nil.

I had code compiling with C++20 using XCode 14.3. I now updated to XCode 15.4, and that feature is not available anymore... No member named 'join' in namespace 'std::ranges::views' Why is join got dropped?

When I Run Php Artisan Command in PhpStorm Laravel Project The below results show in the terminal. dyld[11387]: Library not loaded: @loader_path/../../../../opt/icu4c/lib/libicuio.73.dylib Referenced from: <27B43AEF-470B-32CD-9521-AA834300394F> /usr/local/Cellar/php/8.2.10/bin/php Reason: tried: '/usr/local/Cellar/php/8.2.10/bin/../../../../opt/icu4c/lib/libicuio.73.dylib' (no such file), '/usr/local/lib/libicuio.73.dylib' (no such file), '/usr/lib/libicuio.73.dylib' (no such file, not in dyld cache) zsh: abort php artisan

Is it possible to access the RoomPlan API from Objective-C? I cannot figure out how to include the RoomPlan framework into some legacy Objective-C code I have. I can include the RoomPlan.h header but it still does not recognize any of the API classes. I also could not figure out if there was a way to use RoomPlan-Swift.h to expose the API to the Objective-C code.

if we define a property in the following way: @property (atomic) NSString *latestObject; Can we assume that the read write to that value is thread safe? i.e the value will be correct. Or it is better to write our own setter/getter with Locks?

White-label messaging is like a pre-made chat app that one company creates, but other companies can make it look like it’s their own by changing its appearance and name. Basically, it’s a chat tool that businesses can buy and use with their own branding.

I have a sandboxed app in /Applications. I'm attempting to shoot a problem with LLDB, so I cd to /Applications/app-name/Contents/MacOS and do lldb programname. However, once I fire it off with "r" it dies instantly with: error: process exited with status -1 (lost connection) Should this work? Should I try signing the lldb executable? Thanks!