Compiler

RSS for tag

Discuss the various compiler and toolchain technologies used in development.

Posts under Compiler tag

57 Posts

Post

Replies

Boosts

Views

Activity

Investigating Third-Party IDE Integration Problems
I regularly see questions from folks who’ve run into problems with their third-party IDE on macOS. Specifically, the issue is that their IDE is invoking Apple’s command-line tools — things like clang and ld — and that’s failing in some way. This post collects my ideas on how to investigate, and potentially resolve, issues like this. If you have any questions or comments, please put them in a new thread here on DevForums. Tag it appropriately so that I see it. Good tags include Compiler, Linker, LLVM, and Command Line Tools. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Investigating Third-Party IDE Integration Problems Many third-party IDEs rely on Apple tools. For example, the IDE might run clang to compile C code or run ld to link object files. These IDEs typically don’t include the tools themselves. Rather, they rely on you to install Xcode or Apple’s Command Line Tools package. These are available at Apple > Developer > Downloads Occasionally I see folks having problems with this. They most typically report that basic stuff, like compiling a simple C program, fails with some mysterious error. If you’re having such a problem, follow the steps below to investigate it. IMPORTANT Some IDEs come with their own tools for compiling and linking. Such IDEs are not the focus of this post. If you have problems with an IDE like that, contact its vendor. Select Your Tools macOS has a concept of the current command-line tools. This can either point to the tools within Xcode or to an installed Command Line Tools package. To see which tools are currently selected, run xcode-select with the --print-path argument. This is what you’ll see if you have Xcode installed in the Applications folder: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer Note All of the tools I discuss here are documented in man pages. If you’re not familiar with those, see Reading UNIX Manual Pages. And this is what you’ll see with a Command Line Tools package selected. % xcode-select --print-path /Library/Developer/CommandLineTools There are two common problems with this: It points to something you’ve deleted. It points to something unexpected. Run the command above to see the current state. If necessary, change the state using the --switch option. For example: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % sudo xcode-select --switch ~/XcodeZone/Xcode-beta.app % clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … I have Xcode 14.3 in the Applications folder and thus clang runs Clang 14.0.3. I have Xcode 15.0b5 in ~/XcodeZone, so switching to that yields Clang 15.0.0. It’s possible to run one specific command with different tools. See Select Your Tools Temporarily, below. Run a Simple Test A good diagnostic test is to use the selected command-line tools to compile a trivial test program. Consider this C [1] example: % cat hello.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } % clang -o hello hello.c % ./hello Hello Cruel World! IMPORTANT If possible, run this from Terminal rather than, say, over SSH. You may need to expand this test program to exercise your specific case. For example, if your program is hitting an error when it tries to import the Core Foundation framework, add that import to your test program: % cat hello.c #include <stdio.h> #include <CoreFoundation/CoreFoundation.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } When you compile your test program, you might see one of these results: Your test program compiles. Your test program fails with a similar error. Your test program fails with a different error. I’ll explore each case in turn. [1] For a C++ example, see C++ Issues, below. If your test program compiles… If your test program compiles from the shell, that proves that your basic command-line tools setup is fine. If the same program fails to compile in your IDE, there’s something IDE-specific going on here. I can’t help you with that. I recommend that you escalate the issue via the support channel for your IDE. If your test program fails with a similar error… If your test program fails with an error similar to the one you’re seeing in your IDE, there are two possibilities: There’s a bug in your test program’s code. There’s an environmental issue that’s affecting your command-line tools setup. Don’t rule out the first possibility. I regularly see folks bump into problems like this, where it turns out to be a bug in their code. For a specific example, see C++ Issues, below. Assuming, however, that your test program’s code is OK, it’s time to investigate environmental issues. See Vary Your Environment, below. If your test program fails with a different error… If your test program fails with a different error, look at the test program’s code to confirm that it’s correct, and that it accurately reflects the code you’re trying to run in your IDE. Vary Your Environment If your test program fails with the same error as you’re seeing in your IDE, and you are sure that the code is correct, it’s time to look for environmental factors. I typically do this with the steps described in the next sections, which are listed from most to least complex. These steps only tell you where things are going wrong, not what is going wrong. However, that’s often enough to continue the investigation of your issue. Vary Your Shell Try running your commands in a different shell. macOS’s default shell is zsh. Try running your commands in bash instead: % bash … bash-3.2$ clang -o hello hello.c bash-3.2$ ./hello Hello Cruel World! Or if you’ve switched your shell to bash, try it in zsh. Vary Your User Account Some problems are caused by settings tied to your user account. To investigate whether that’s an issue here: Use System Settings > Users & Groups to create a new user. Log in as that user. Run your test again. Vary Your Mac Some problems are system wide, so you need to test on a different Mac. The easiest way to do that is to set up a virtual machine (VM) and run your test there. Or, if you have a separate physical Mac, run your test on that. Vary Your Site If you’re working for an organisation, they may have installed software on your Mac that causes problems. If you have a Mac at home, try running your test there. It’s also possible that your network is causing problems [1]. If you have a laptop, try taking it to a different location to see if that changes things. [1] I rarely see this when building a simple test program, but it do see it with other stuff, like code signing. C++ Issues If you’re using C++, here’s a simple test you can try: % cat hello.cpp #include <iostream> int main() { std::cout << "Hello Cruel World!\n"; } % clang++ -o hello hello.cpp % ./hello Hello Cruel World! A classic problem with C++ relates to name mangling. Consider this example: % cat hello.c #include <stdio.h> #include "hello-core.h" int main(int argc, char ** argv) { HCSayHello(); return 0; } % cat hello-core.cpp #include "hello-core.h" #include <iostream> extern void HCSayHello() { std::cout << "Hello Cruel World!\n"; } % cat hello-core.h extern void HCSayHello(); % clang -c hello.c % clang++ -c hello-core.cpp % clang++ -o hello hello.o hello-core.o Undefined symbols for architecture x86_64: "_HCSayHello", referenced from: _main in hello.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The issue here is that C++ generates a mangled name for HCSayHello: % nm hello-core.o | grep HCSayHello 0000000000000000 T __Z10HCSayHellov whereas C uses the non-mangled name: % nm hello.o | grep HCSayHello U _HCSayHello The fix is an appropriate application of extern "C": % cat hello-core.h extern "C" { extern void HCSayHello(); }; Select Your Tools Temporarily Sometimes you want to temporarily run a command from a particular tools package. To continue my earlier example, I currently have Xcode 14.3 installed in the Applications folder and Xcode 15.0b5 in ~/XcodeZone. Xcode 14.3 is the default but I can override that with the DEVELOPER_DIR environment variable: % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % DEVELOPER_DIR=~/XcodeZone/Xcode-beta.app/Contents/Developer clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … Revision History 2025-01-27 Remove the full width characters. These were a workaround for a forums platform bug that’s since been fixed. Made other minor editorial changes. 2023-07-31 First posted.
0
0
1.8k
Jan ’25
[Xcode:BuildSettings] Keep some warnings as warnings while the rest as errors
We have a big iOS project and we are using .xcconfig files to define our compiler options and build settings. We have our SWIFT_TREAT_WARNINGS_AS_ERRORS set to YES so that all Swift related warnings will be reported as errors. Now, we are trying to migrate to Xcode 16.1 and set 'targeted' in the 'Strict Concurrency Checking' flag. This produces some errors that are related to Swift's concurrency checks. We are now planning to have an approach where we still want to keep SWIFT_TREAT_WARNINGS_AS_ERRORS as is but we want all concurrency related warnings to be still treated as warnings while the rest will get reported as errors. We found this new compiler option - https://forums.swift.org/t/warnings-as-errors-exceptions/72925. It looks like the one we want but I think it is still not out yet and we need to wait until Swift 6.1 (correct me if im wrong). Or is there any other way to do what we want to achieve?
0
0
332
Jan ’25
Cannot catch `std::invalid_argument` on clang++ under m1 -fno-rtti
Today I got stuck with a weird behaviour with my c++ project. There is the code which doesn't catch exception from standard library (the same snippet works well on intel mac and under linux machines). Code snippet: #include &lt;exception&gt; #include &lt;stdexcept&gt; #include &lt;iostream&gt; #include &lt;string&gt; int main() { try { std::stod("notanumber"); } catch (const std::invalid_argument&amp;) { std::cerr &lt;&lt; "Caught std::invalid_argument" &lt;&lt; std::endl; } } Compilation command: clang++ -fno-rtti main.cpp -o main &amp;&amp; ./main Clang versions: clang++ --version Homebrew clang version 15.0.3 Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /opt/homebrew/opt/llvm/bin Also tried: Apple clang version 14.0.0 (clang-1400.0.29.102) Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Output: libc++abi: terminating with uncaught exception of type std::invalid_argument: stod: no conversion [1] 65643 abort ./main Expected output: Caught std::invalid_argument Other info: Chip: Apple M1 OS: 12.6
4
0
1.6k
Dec ’24
Trying to understand Swift-C++ interopability
Hi, I'm struggling to understand using Swift-C++ in the same project. I have an existing code-base that makes heavy use of Swift-Objective-C interoperability. We make use of swift classes in our project. When I enable swift-objective c interoperability I am running into numerous build errors in the generated bridging header. I'm trying to understand why these errors exist and what to do to get around them. I have a project that I've set up with some test code, and I'm running into an error here: public class Foo { let name: String public init(name: String) { self.name = name } } public class Bar { let name: String public init(name : String) { self.name = name; } public func getFoo() -> Foo { return Foo(name: self.name); } } In the header file: Unknown type name 'Foo' SWIFT_INLINE_THUNK Foo getFoo() SWIFT_SYMBOL("s:13ForestBuilder3BarC6getFooAA0E0CyF"); This error goes away if I use structs, but for the purposes of porting my codebase, I'd prefer to use classes. Do classes not play nice here? Or am I misunderstanding something. Thanks.
0
0
428
Dec ’24
XCode 16 clang++ compiler generates unexpected results for conditional checks at -O2 and -O3 optimization levels
Around a month back, developers of the OpenJDK project, when using XCode 16 to build the JDK started noticing odd failures when executing code which was compiled using the clang++ compiler shipped in that XCode 16 release (details in https://bugs.openjdk.org/browse/JDK-8340341). Specifically, a trivial for loop in a c++ code of the form: int limit = ... // method local variable for (i=0; i<limit; i++) { ... } ends up iterating more times than the specified limit. The "i<limit" returns true even when it should have returned false. In fact, debug log messages within the for loop of the form: fprintf(stderr, "parsing %d of %d, %d < % d == %s", i, limit, i, limit, (i<limit) ? "true" : "false"); would show output of the form: parsing 0 of 2, 0 < 2 == true parsing 1 of 2, 1 < 2 == true parsing 2 of 2, 2 < 2 == true Notice, how it entered the for loop even when 2 < 2 should have prevented it from entering it. Furthermore, notice the message says 2 < 2 == true (which clearly isn't right). This happens when that code is compiled with optimization level -O2 or -O3. The issue doesn't happen with -O1. I had reported this as an issue to Apple through feedback assistance, more than a month back. The feedback id is FB15162411. There hasn't been any response to it nor any indication that the issue has been noticed and can be reproduced (the steps to reproduce have been provided in that issue). In the meantime, more and more users are now running into this failure in JDK when using XCode 16. We haven't put any workaround in place (the only workaround we know of is using -O1 for the compilation of this file) because it isn't clear what exactly is causing this issue (other than the fact that it shows up with specific optimization levels). It's also unknown if this bug has wider impact. Would it be possible to check if FB15162411 is being looked into and any technical details on what's causing this? That would help us decide if it's OK to put in place a temporary workaround in the OpenJDK build and how long to maintain that workaround. For reference, this was reproduced on: clang++ --version Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin23.6.0 Thread model: posix InstalledDir: /xcode-16/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
13
1
2.0k
Dec ’24
The Peril of the Ampersand
A few years ago [1] Xcode added new warnings that help detect a nasty gotcha related to the lifetime of unsafe pointers. For example: Initialization of 'UnsafeMutablePointer<timeval>' results in a dangling pointer Inout expression creates a temporary pointer, but argument 'iov_base' should be a pointer that outlives the call to 'init(iov_base:iov_len:)' I’ve seen a lot of folks confused by these warnings, and by the lifetime of unsafe pointers in general, and this post is my attempt to clarify the topic. If you have questions about any of this, please put them in a new thread in the Programming Languages > Swift topic. Finally, I encourage you to watch the following WWDC presentations: WWDC 2020 Session 10648 Unsafe Swift WWDC 2020 Session 10167 Safely manage pointers in Swift These cover some of the same ground I’ve covered here, and a lot of other cool stuff as well. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@apple.com" [1] Swift 5.2.2, as shipped in Xcode 11.4. See the discussion of SR-2790 in Xcode 11.4 Release Notes. Basics In Swift, the ampersand (&) indicates that a parameter is being passed inout. Consider this example: func addVarnish(_ product: inout String) { product += " varnish" } var waffle = "waffle" addVarnish(&waffle) // line A print(waffle) // printed: waffle varnish On line A, the ampersand tells you that waffle could be modified by addVarnish(_:). However, there is another use of ampersand that was designed to help with C interoperability. Consider this code: var tv = timeval() gettimeofday(&tv, nil) print(tv) // printed: timeval(tv_sec: 1590743104, tv_usec: 77027) The first parameter to gettimeofday is an UnsafeMutablePointer<timeval>. Here the ampersand denotes a conversion from a timeval to an UnsafeMutablePointer<timeval>. This conversion makes it much easier to call common C APIs from Swift. This also works for array values. For example: var hostName = [CChar](repeating: 0, count: 256) gethostname(&hostName, hostName.count) print(String(cString: hostName)) // printed: slimey.local. In this code the ampersand denotes a conversion from [CChar] to an UnsafeMutablePointer<CChar> that points to the base of the array. While this is convenient, it’s potentially misleading, especially if you come from a C background. In C-based languages, using ampersand in this way yields a pointer to the value that’s valid until the value gets deallocated. That’s not the case in Swift. Rather, the pointer generated by the ampersand syntax is only valid for the duration of that function call. To understand why that’s the case, consider this code: struct TimeInTwoParts { var sec: time_t = 0 var usec: Int32 = 0 var combined: timeval { get { timeval(tv_sec: sec, tv_usec: usec) } set { sec = newValue.tv_sec usec = newValue.tv_usec } } } var time = TimeInTwoParts() gettimeofday(&time.combined, nil) // line A print(time.combined) // printed: timeval(tv_sec: 1590743484, tv_usec: 89118) print(time.sec) // printed: 1590743484 print(time.usec) // printed: 89118 Here combined is a computed property that has no independent existence in memory. Thus, it simply makes no sense to take the address of it. So, how does ampersand deal with this? Under the covers the Swift compiler expands line A to something like this: var tmp = time.combined gettimeofday(&tmp, nil) time.combined = tmp Once you understand this it’s clear why the resulting pointer is only valid for the duration of the call: As soon as Swift cleans up tmp, the pointer becomes invalid. A Gotcha This automatic conversion can be a nasty gotcha. Consider this code: var tv = timeval() let tvPtr = UnsafeMutablePointer(&tv) // line A // ^~~~~~~~~~~~~~~~~~~~~~~~~ // Initialization of 'UnsafeMutablePointer<timeval>' results in a dangling pointer gettimeofday(tvPtr, nil) // line B This results in undefined behaviour because the pointer generated by the ampersand on line A is no longer valid when it’s used on line B. In some cases, like this one, the later Swift compiler is able to detect this problem and warn you about it. In other cases you’re not so lucky. Consider this code: guard let f = fopen("tmp.txt", "w") else { … } var buf = [CChar](repeating: 0, count: 1024) setvbuf(f, &buf, _IOFBF, buf.count) // line A let message = [UInt8]("Hello Crueld World!".utf8) fwrite(message, message.count, 1, f) // line B fclose(f) // line C This uses setvbuf to apply a custom buffer to the file handle. The file handle uses this buffer until after the close on line C. However, the pointer created by the ampersand on line A only exists for the duration of the setvbuf call. When the code calls fwrite on line B the buffer pointer is no longer valid and things end badly. Unfortunately the compiler isn’t able to detect this problem. Worse yet, the code might actually work initially, and then stop working as you change optimisation settings, update the compiler, change unrelated code, and so on. Another Gotcha There is another gotcha associated with the ampersand syntax. Consider this code: class AtomicCounter { var count: Int32 = 0 func increment() { OSAtomicAdd32(1, &count) } } This looks like it’ll implement an atomic counter but there’s no guarantee that the counter will be atomic. To understand why, apply the tmp transform from earlier: class AtomicCounter { var count: Int32 = 0 func increment() { var tmp = count OSAtomicAdd32(1, &tmp) count = tmp } } So each call to OSAtomicAdd32 could potentially be operating on a separate copy of the counter that’s then assigned back to count. This undermines the whole notion of atomicity. Again, this might work in some builds of your product and then fail in other builds. Note The above discussion is now theoretical because Swift 6 added a Synchronization module that includes comprehensive support for atomics. That module also has a Mutex type (if you need a mutex on older platforms, check out OSAllocatedUnfairLock). These constructs use various different mechanisms to ensure that the underlying value has a stable address. Summary So, to summarise: Swift’s ampersand syntax has very different semantics from the equivalent syntax in C. When you use an ampersand to convert from a value to a pointer as part of a function call, make sure that the called function doesn’t use the pointer after it’s returned. It is not safe to use the ampersand syntax for functions where the exact pointer matters. It’s Not Just Ampersands There’s one further gotcha related to arrays. The gethostname example above shows that you can use an ampersand to pass the base address of an array to a function that takes a mutable pointer. Swift supports two other implicit conversions like this: From String to UnsafePointer<CChar> — This allows you to pass a Swift string to an API that takes a C string. For example: let greeting = "Hello Cruel World!" let greetingLength = strlen(greeting) print(greetingLength) // printed: 18 From Array<Element> to UnsafePointer<Element> — This allows you to pass a Swift array to a C API that takes an array (in C, arrays are typically represented as a base pointer and a length). For example: let charsUTF16: [UniChar] = [72, 101, 108, 108, 111, 32, 67, 114, 117, 101, 108, 32, 87, 111, 114, 108, 100, 33] print(charsUTF16) let str = CFStringCreateWithCharacters(nil, charsUTF16, charsUTF16.count)! print(str) // prints: Hello Cruel World! Note that there’s no ampersand in either of these examples. This technique only works for UnsafePointer parameters (as opposed to UnsafeMutablePointer parameters), so the called function can’t modify its buffer. As the ampersand is there to indicate that the value might be modified, it’s not used in this immutable case. However, the same pointer lifetime restriction applies: The pointer passed to the function is only valid for the duration of that function call. If the function keeps a copy of that pointer and then uses it later on, Bad Things™ will happen. Consider this code: func printAfterDelay(_ str: UnsafePointer<CChar>) { print(strlen(str)) // printed: 18 DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { print(strlen(str)) // printed: 0 } } let greeting = ["Hello", "Cruel", "World!"].joined(separator: " ") printAfterDelay(greeting) dispatchMain() The second call to strlen yields undefined behaviour because the pointer passed to printAfterDelay(_:) becomes invalid once printAfterDelay(_:) returns. In this specific example the memory pointed to by str happened to contain a zero, and hence strlen returned 0 but that’s not guaranteed. The str pointer is dangling, so you might get any result from strlen, including a crash. Advice So, what can you do about this? There’s two basic strategies here: Extend the lifetime of the pointer Manual memory management Extending the Pointer’s Lifetime The first strategy makes sense when you have a limited number of pointers and their lifespan is limited. For example, you can fix the setvbuf code from above by changing it to: let message = [UInt8]("Hello Crueld World!".utf8) guard let f = fopen("tmp.txt", "w") else { … } var buf = [CChar](repeating: 0, count: 1024) buf.withUnsafeMutableBufferPointer { buf in setvbuf(f, buf.baseAddress!, _IOFBF, buf.count) fwrite(message, message.count, 1, f) fclose(f) } This version of the code uses withUnsafeMutableBufferPointer(_:). That calls the supplied closure and passes it a pointer (actually an UnsafeMutableBufferPointer) that’s valid for the duration of that closure. As long as you only use that pointer inside the closure, you’re safe! There are a variety of other routines like withUnsafeMutableBufferPointer(_:), including: The withUnsafeMutablePointer(to:_:) function The withUnsafeBufferPointer(_:), withUnsafeMutableBufferPointer(_:), withUnsafeBytes(_:), and withUnsafeMutableBytes(_:) methods on Array The withUnsafeBytes(_:) and withUnsafeMutableBytes(_:) methods on Data The withCString(_:) and withUTF8(_:) methods on String. Manual Memory Management If you have to wrangle an unbounded number of pointers — or the lifetime of your pointer isn’t simple, for example when calling an asynchronous call — you must revert to manual memory management. Consider the following code, which is a Swift-friendly wrapper around posix_spawn: func spawn(arguments: [String]) throws -> pid_t { var argv = arguments.map { arg -> UnsafeMutablePointer<CChar>? in strdup(arg) } argv.append(nil) defer { argv.forEach { free($0) } } var pid: pid_t = 0 let success = posix_spawn(&pid, argv[0], nil, nil, argv, environ) == 0 guard success else { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno), userInfo: nil) } return pid } This code can’t use the withCString(_:) method on String because it has to deal with an arbitrary number of strings. Instead, it uses strdup to copy each string to its own manually managed buffer. And, as these buffers are manually managed, is has to remember to free them. Change History 2024-12-11 Added a note about the Synchronization module. Made various editorial changes. 2021-02-24 Fixed the formatting. Added links to the WWDC 2021 sessions. Fixed the feedback advice. Minor editorial changes. 2020-06-01 Initial version.
0
0
9.9k
Dec ’24
Apple Clang generating incorrect SIMD code
I have an M2 Mac Mini with Apple Clang 16.0.0. Under certain circumstances, the SIMD code generated by an unrolled loop is incorrect. I have a short example program which reproduces the bug, on my machine and someone else's with the same Clang version. The core operation is this: for (size_t i = 0; i < count; ++i) { c[i] = a[i]*std::conj(b[i]); } This loop gets unrolled to process 4 elements at once, and when count=15, the first 12 results have the wrong sign for the imaginary part. The final 3 elements are correct, since those are processed in a different code path. Is this an known error? I suspect it might be present in other Apple Clang versions as well (because I found this while chasing down an extremely unpredictable bug) but so far this is the only setup where I've cleanly reproduced it. Minimal test program (43 lines): https://signalsmith-audio.co.uk/tmp/argh.git/ - just run make. The expected output is a bunch of error=0, or small values from floating-point errors. I'm getting results like error=0.229711, and you can see it's because the "actual" results have a ± error.
4
2
719
Dec ’24
Reading debug symbols from binary
Hello, I am trying to read debug symbols from a binary obtained from simple "hello world" C code. I use default gcc (Clang) on macos15, then try to install gcc-14 with hombrew $ gcc -g program.c -o program then run $ dsymutil program I got : warning: no debug symbols in executable (-arch arm64) I am doing something wrong here. My final objective is to be able to use my binaries in total view for debugging. Without debugging symbols, I can debug properly . Thank you
1
0
671
Dec ’24
Xcode 16.2 Beta 3 makes min deploy to iOS 16 for swift/cpp mixed projects
Below copied from my original post here: https://forums.swift.org/t/xcode-16-2-beta-seems-increase-the-min-deploy-to-16-0-for-swift-cpp-mixed-project/76221 Our games are set to min deploy of iOS 12.0. When building with the Xcode 16.2 beta3, the Xcode 16.1 build-able project will have errors for those static libs that has swift mixed with C++: Compiling for iOS 12.0, but module 'Cxx' has a minimum deployment target of iOS 16.0: /Users/trout.zhang/Documents/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/Cxx.swiftmodule/arm64-apple-ios.swiftmodule Change that static lib min deploy to 16.0 can make the build succeed, while maintain the exe target still use iOS 12.0. I am not familiar with how the min deploy works, is it: choosing the highest of exe and its dependencies, thus effectively set the final product has min deploy of iOS 16.0 or maintaining exe's iOS 12.0 and actually crash in runtime if the iOS is less than 16.0, when reach the code in that static lib. Apparently, non of the above is what we want. Use cat in cmdline, for Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos/Cxx.swiftmodule/arm64-apple-ios.swiftdoc with both Xcode.app(16.1) and Xcode-beta.app(16.2 beta3), I found the different lines: Xcode 16.1 has: Apple Swift version 6.0.2 effective-5.10 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)Cxx?arm64-apple-ios11.0 Xcode 16.2 beta 3 has: Apple Swift version 6.0.3 effective-5.10 (swiftlang-6.0.3.1.8 clang-1600.0.30.1)Cxx?arm64-apple-ios16.0
0
2
921
Nov ’24
Different optimization level for package dependencies
I am using DuckDB as an external dependency in my project. The package is basically a Swift wrapper around C++ code. If I run my app in Debug mode, then the performance of the library is an order of magnitude slower than when I run it in Release mode. In Release mode it is really fast, but compilation times are too slow. I am a complete beginner to Xcode's build system and was wondering if there was any way to have the best of both worlds? For example, by compiling my SwiftUI code without optimizations but having it linked to a static and optimized version of the library.
0
0
415
Nov ’24
Token is not a valid binary operator in a preprocessor subexpression
I have a relatively unique project layered with file types (top to bottom) SwiftUI, Swift, Objective C, and C. The purpose of this layering is that I have a C language firmware application framework for development of firmware on custom electronic boards. Specifically, I use the standard C preprocessor in specific ways to make data driven structures, not code. There are header files shared between the firmware project and the Xcode iPhone app to set things like the BLE protocol and communication command/reply protocols, etc. The app is forced to adhere to that defined by the firmware, rather than rely a design to get it right. The Objective C code is mainly to utilize the Bluetooth stack provided by iOS. I specifically use this approach to allow C files to be compiled. Normally, everything has worked perfectly, but a serious and obtuse problem just surfaced a couple days ago. My important project was created long ago. More recently, I started a new project using most of the same technology, but its project is newer. Ironically, it continues to work perfectly, but ironically the older project stopped working. (Talking about the Xcode iOS side.) Essentially, the Objective C handling of the C preprocessor is not fully adhering to the standard C preprocessing in one project. It's very confusing because there is no code change. It seems Xcode was updated, but looks like the project was not updated, accordingly? I'm guessing there is some setting that forces Objective C to adhere to the standard C preprocessor rules. I did see a gnu compiler version that did not get updated compared to the newer project, but updating that in the Build Settings did not fix the problem. The error is in the title: Token is not a valid binary operator in a preprocessor subexpression. The offending macro appears in a header file, included in several implementation files. Compiling a single implementation files isolates the issue somewhat. An implementation with no Objective C objects compiles just fine. If there are Objective C objects then I get the errors. Both cases include the same header. It seems like the Objective C compiler, being invoked, uses a different C preprocessor parser, rather than the standard. I guess I should mention the bridging header file where these headers exist, as well. The offending header with the problem macro appears as an error in the bridging header if a full build is initiated. Is there an option somewhere, that forces the Objective C compiler to honor the standard C processor? Note, one project seems to. #define BLE_SERVICE_BLANK( enumTag, uuid, serviceType ) #define BLE_CHARACTERISTIC_BLANK( enumTag, uuid, properties, readPerm, writePerm, value) #define BLE_SERVICE_ENUM_COUNTER( enumTag, uuid, serviceType) +1 #define BLE_CHARACTERISTIC_ENUM_COUNTER( enumTag, uuid, properties, readPerm, writePerm, value) +1 #if 0 BLE_SERVICE_LIST(BLE_SERVICE_ENUM_COUNTER, BLE_CHARACTERISTIC_BLANK) &gt; 0 #define USING_BLE_SERVICE ... #if 0 BLE_SERVICE_LIST(BLE_SERVICE_BLANK, BLE_CHARACTERISTIC_ENUM_COUNTER) &gt; 0 #define USING_BLE_CHARACTERISTIC ... token is not a valid binary operator in a preprocessor subexpression refers to the comparison. BLE_SERVICE_LIST() does a +1 for each item in the list. There is no further expansion. One counts services. The other counts characteristics. The errors are associated with the comparisons.
8
0
1.1k
Nov ’24
Xcodecloud Xcodebuild Failed With Exit Code 70
I'm running on xcode 16, the project archives just fine on the local machine. However, with xcodecloud. It's running into exist code 70 on the following command xcodebuild -exportArchive -archivePath ..... #output Showing All Errors Only Build Archive Export archive for ad-hoc distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for development distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for app-store distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70
6
1
3.5k
Nov ’24
compilation error in CoreFoundation - visionos
when trying to build wireshark I'm getting the following, any idea how to solve it? [ 13%] Building C object wsutil/CMakeFiles/wsutil.dir/os_version_info.c.o In file included from wireshark/wsutil/os_version_info.c:23: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:54: /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:676:195: error: expected ',' 676 | void *CFAllocatorAllocateTyped(CFAllocatorRef allocator, CFIndex size, CFAllocatorTypeID descriptor, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:679:211: error: expected ',' 679 | void *CFAllocatorReallocateTyped(CFAllocatorRef allocator, void *ptr, CFIndex newsize, CFAllocatorTypeID descriptor, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:682:165: error: expected ',' 682 | void *CFAllocatorAllocateBytes(CFAllocatorRef allocator, CFIndex size, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:685:181: error: expected ',' 685 | void *CFAllocatorReallocateBytes(CFAllocatorRef allocator, void *ptr, CFIndex newsize, CFOptionFlags hint) API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); | ^ In file included from wireshark/wsutil/os_version_info.c:23: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:73: /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFNumberFormatter.h:144:147: error: expected ',' 144 | CF_EXPORT const CFNumberFormatterKey kCFNumberFormatterMinGroupingDigits API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0), visionos(2.0)); // CFNumber | ^ 5 errors generated. make[2]: *** [wsutil/CMakeFiles/wsutil.dir/os_version_info.c.o] Error 1 make[1]: *** [wsutil/CMakeFiles/wsutil.dir/all] Error 2 make: *** [all] Error 2
1
0
576
Nov ’24
FCP Workflow extension does not build with clang unknown argument -e_ProExtensionMain in Xcode 16
With Xcode 16 I cant make the Final Cut Extension Workflow work. I am quite sure I was able to add the Workflow Extension target a couple of months ago in Xcode 15 and did successfully build it, but in Xcode 16 it wont build and it fails with this error: clang: error: unknown argument: '-e_ProExtensionMain' I have installed multiple times Workflow Extensions SDK 1.0.2 and even disabled Library validation like its described in the release notes but I dont think thats the problem here. Seems like clang doesn't have the arguments for it, I guess the SDK should add these but seems like something got messed up - the template shows up fine in Xcode. I reinstalled Xcode and command line tools but that didnt help. Checking clang it really doesnt have the argument. But where does the SDK add this? Xcode seems to be using internal clang and /usr/bin/clang doesn't have it either. Any tips what could be the problem here? I was not really able to locate the SDK to remove it before trying to install again - any ideas? Steps to reproduce Create new project Add FCP workflow extension target Build -> it fails Same behaviour with 16.1 Beta. I am running Sonoma 14.7. Thanks in advance for any ideas!
4
0
808
Oct ’24
Build options in Xcode
I have a few questions on build options. Deployment post processing - is this for Mac apps? Or is it a setting for Xcode ? Does "Symbols hidden by default" set to yes enable symbolicated crash dumps? Can "Product name" and "Product module name" be different from bundleID component? Generate_Info_Plist is set to no. Will the Application Category value be reflected if there is no Info_plist file generated? I notice in my tests that the category is always wrong and defaults to team name. Privacy - GameKit Friend List Usage Description should this be yes or no if I am using Apple suggested privacy preserving scoped identifier gamePlayerID? Install Group/Permissions/Owner are these referring to setting in Dev environment or are these Mac App Only settings? ( I was not sure if iOS like Unix, has system users exposed at this high level anyway ) How do I export copy of existing build settings to a xconfig file? There was talk of a tool not sure if it is still available. For my TestFlight build for stress testing , what options would you recommend to help debug and trace easily ? Note I have tested the build with various Address Sanitizer, Memory Sanitizer, Guard malloc etc. options enabled to prep but haven't turned any of those on for the test build. Should I be enabling some? ( Some do not work together ) Alternately, if there is a document or video that addresses all of the above please let me know! Thanks in advance!!
2
0
584
Oct ’24
The compiler is unable to type-check this expression in reasonable time
This is one of the worst errors you can encounter while developing with Xcode. It looks like it's related to a problem inside the compiler itself: when there are lot of lines of code, it becomes unable to identify them all and start asking you to break down the code in smaller pieces. Sometimes you can, sometimes not. First of all, in your code there is FOR SURE an error, so in case of the second option, begin commenting entires sections of your code: this can lead to two options: You commented a section that contains the error: Xcode give you the preview and you check the commented section to find the error You commented enough code to let the compiler do its job, and you'll have the normal error reported in your code: again, fix it! Once errors have been fixed, normally you can uncomment what you excluded and all will go up and ok again. The most common errors that can lead to this behavior (but it's just a hint) are those involving parameters got or passed to other SwiftUI objects: parameters label (mistyped, missing, exceeding) parameters values (not $/& present, $/& present but not required) parameters types (you passed a wrong type) Well, I hope that this post could be useful to others that, like I did, are struggling a lot to understand the exact nature of this peculiar error. Code well and Prosper!
0
1
601
Oct ’24
Xcode 16's clang : failure to recognise function type for static member function template in class template
Hello, It appears that clang version provided by Xcode 16 brings this compilation error seen in previous LLVM version : https://github.com/llvm/llvm-project/issues/91362 Fixed in : https://github.com/llvm/llvm-project/pull/90760 #include <type_traits> template <typename T> struct class_tmpl { template <bool B> static int call_e() { return 0; } template <bool B> static int call_ne() noexcept { return 0; } template <bool B> static int call() noexcept(std::is_nothrow_copy_assignable<T>::value) { return 0; } }; int main(int argc, char *argv[]) { using function_ptr = int (*)(); function_ptr f1 = &class_tmpl<int>::call_e<false>; function_ptr f2 = &class_tmpl<int>::call_ne<false>; function_ptr f3 = &class_tmpl<int>::call<false>; return 0; } $ clang -std=c++17 main.cpp main.cpp:15:24: error: address of overloaded function 'call' does not match required type 'int ()' 15 | function_ptr f3 = &class_tmpl<int>::call<false>; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ main.cpp:7:34: note: candidate template ignored: substitution failure [with B = false] 7 | template <bool B> static int call() noexcept(std::is_nothrow_copy_assignable<T>::value) { return 0; } | ^ 1 error generated. Compiler informations : clang --version Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin24.0.0
2
0
5.0k
Oct ’24