I had a swift compiler errors of this type : "Cannot find type 'int' in scope" here is my code . Any idea? thanks

Hi all, Our Objective-C project has quite a few Swift submodule that are linked with static Mach-O. The submodules are built and used in Objective-C files (.m, .mm) using the syntax #import <MyModule/MyModule-Swift.h> Since Xcode 14.3 and the early versions of Xcode 15.0, whenever I make any code changes in the .m .mm files (even just a space), all files using the Swift submodules are rebuilt. During my checks, I noticed the generated header of the submodules (MyModule-Swift.h) is regenerated even when its content hasn't changed. The modification time of the header file leads to the rebuilding of all Objective-C files. Of course, our project has a clean build when importing *-Swift.h in the .pch file, sometimes errors are thrown due to header changes during the build process. This behavior was not present in Xcode 14.2. More info I've tried configuring some flags in the Build settings, but they didn't work. Does anyone have any solutions to suggest for fixing this issue and saving our project ? :( Thanks!

Hello, I am with a long running project that is written in Objective-c and Swift (more). I have added a widget target extension to the project, but can't compile since there is this issue: What is the potential problem and how to solve it? = swiftsourceinfo Multiple commands produce '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/Project/arm64-apple-ios-simulator.swiftsourceinfo' Target 'MyApp' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyApp.build/Objects-normal/arm64/MyApp.swiftsourceinfo' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/Project/arm64-apple-ios-simulator.swiftsourceinfo' Target 'MyAppWidgetsExtension' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyAppWidgetsExtension.build/Objects-normal/arm64/MyApp.swiftsourceinfo' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/Project/arm64-apple-ios-simulator.swiftsourceinfo' = arm64-apple-ios-simulator.abi.json Multiple commands produce '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.abi.json' Target 'MyApp' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyApp.build/Objects-normal/arm64/MyApp.abi.json' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.abi.json' Target 'MyAppWidgetsExtension' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyAppWidgetsExtension.build/Objects-normal/arm64/MyApp.abi.json' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.abi.json' = .swiftdoc Multiple commands produce '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftdoc' Target 'MyApp' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyApp.build/Objects-normal/arm64/MyApp.swiftdoc' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftdoc' Target 'MyAppWidgetsExtension' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyAppWidgetsExtension.build/Objects-normal/arm64/MyApp.swiftdoc' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftdoc' = .swiftmodule Multiple commands produce '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftmodule' Target 'MyApp' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyApp.build/Objects-normal/arm64/MyApp.swiftmodule' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftmodule' Target 'MyAppWidgetsExtension' (project 'MyApp') has copy command from '.../Build/Intermediates.noindex/MyApp.build/Debug-iphonesimulator/MyAppWidgetsExtension.build/Objects-normal/arm64/MyApp.swiftmodule' to '.../Build/Products/Debug-iphonesimulator/MyApp.swiftmodule/arm64-apple-ios-simulator.swiftmodule'

Hi, I am running Mac Intel I7 post 2020 with Sonoma and clang 15.0 . The Clang 15.0 makes c++ code running 5 times slower than it was before upgrade from Ventura 13.6 and Clang 14.3.1 The other trouble is that Sonoma does not allow to revert to Clang 14.3.1 . I do not use Xcode only command line tools . here my options : g++ -std=c++17 -Ofast -march=native -funroll-loops -flto -DNDEBUG -o a prog.cpp So what happened to C++ ?

I'm trying to run the program below on my M1 Pro MacBook Pro from the command line, but I am getting linker errors. Also, I do not want to use XCode, I like to develop in vim in my terminal and want to develop in the terminal rather than XCode. #include <iostream> #include <string> inline void print_string(std::string s = "Hello World!") { std::cout << s << std::endl; } int main() { print_string(); } The above program generates these errors: Undefined symbols for architecture arm64: "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: std::__1::ctype<char> const& std::__1::use_facet<std::__1::ctype<char> >(std::__1::locale const&) in hello_world-fcbd23.o "std::__1::ios_base::getloc() const", referenced from: std::__1::basic_ios<char, std::__1::char_traits<char> >::widen(char) const in hello_world-fcbd23.o "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long)", referenced from: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string<std::__1::nullptr_t>(char const*) in hello_world-fcbd23.o "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(unsigned long, char)", referenced from: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(unsigned long, char) in hello_world-fcbd23.o "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string()", referenced from: _main in hello_world-fcbd23.o std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) in hello_world-fcbd23.o "std::__1::basic_ostream<char, std::__1::char_traits<char> >::put(char)", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::endl<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in hello_world-fcbd23.o "std::__1::basic_ostream<char, std::__1::char_traits<char> >::flush()", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::endl<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in hello_world-fcbd23.o "std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::sentry(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o "std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::~sentry()", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o "std::__1::cout", referenced from: print_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in hello_world-fcbd23.o "std::__1::ctype<char>::id", referenced from: std::__1::ctype<char> const& std::__1::use_facet<std::__1::ctype<char> >(std::__1::locale const&) in hello_world-fcbd23.o "std::__1::locale::~locale()", referenced from: std::__1::basic_ios<char, std::__1::char_traits<char> >::widen(char) const in hello_world-fcbd23.o "std::__1::ios_base::__set_badbit_and_consider_rethrow()", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o "std::__1::ios_base::clear(unsigned int)", referenced from: std::__1::ios_base::setstate(unsigned int) in hello_world-fcbd23.o "std::terminate()", referenced from: ___clang_call_terminate in hello_world-fcbd23.o "___cxa_begin_catch", referenced from: ___clang_call_terminate in hello_world-fcbd23.o std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o "___cxa_call_unexpected", referenced from: std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >::failed() const in hello_world-fcbd23.o std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >::ostreambuf_iterator(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in hello_world-fcbd23.o "___cxa_end_catch", referenced from: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o "___gxx_personality_v0", referenced from: _main in hello_world-fcbd23.o std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hello_world-fcbd23.o std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) in hello_world-fcbd23.o std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >::failed() const in hello_world-fcbd23.o std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >::ostreambuf_iterator(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in hello_world-fcbd23.o std::__1::basic_ios<char, std::__1::char_traits<char> >::widen(char) const in hello_world-fcbd23.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) If I run c code with gcc it works, but for some reason this c++ code isn't working. Is there a fix for this that does not require me to use Xcode?

I’m completely a newbie in the coding world. Been learning C++ for some days. I actually bought my MBA M1 to learn coding. But problems seem to appear whenever I tried to code #include . I use the latest Codelite as my IDE and when I hover towards the red arrow it says the following- error: no member named 'nullptr_t' in the global namespace I have tried this investigation provided by Eskimo - https://developer.apple.com/forums/thread/734833 But again the same errors keep occurring. As a complete newbie, I don’t know much things about these so any help would be amazing for me…. FYI I use the latest clang version as my command line tool and SIP is enabled. I tried restarting my Mac and tried multiple IDEs and code editors like vscode and nano etc. and macOS default terminal, but the the error kept the the same. Also running Ventura 13.3.1 …… Please provide me simply explained instructions to solve this annoying problem…..

macOS flag is: -mmacosx-version-min=xx.yy iphoneos flag is: -mios-version-min=xx.yy iphonesimulator flag is: -mios-simulator-version-min=xx.yy but for xros things are going crazy .... xros flag -mtargetos=xrosxx.yy works well xrsimulator flag -mtargetos=xrosxx.yy or -mtargetos=xrsimulatorxx.yy are not working Does anyone no which is the right flag

Please tell me where I can find the documents for Apple Clang ARM assembler? After I compiled my C source code to ARM assembly code using Apple Clang, it of course generated a lot of ARM assembly code (GNU syntax), but for some of them I can't find related documents, for example the .build_version directive. The generated ARM assembly code is here: .section __TEXT,__text,regular,pure_instructions .build_version macos, 13, 0 sdk_version 13, 3 .globl _main ; -- Begin function main .p2align 2 _main: ; @main .cfi_startproc ; %bb.0: sub sp, sp, #64 str w8, [sp, #16] ; 4-byte Folded Spill stur wzr, [x29, #-4] ; implicit-def: $x8 ... add sp, sp, #64 ret .cfi_endproc ; -- End function .section __TEXT,__cstring,cstring_literals l_.str: ; @.str .asciz "a + b = %d\r\n" .subsections_via_symbols

Running or building the projects but it is showing using build description from memory and its taking too much time.

Hi All, I would like to know if there are any C APIs to control the Floating-Point Control Register (FPCR) on Apple Silicon? The ARM documentation does not show any C APIs for doing this. The only example code looks like VHDL, so I was wondering if any developers here knew of any. Thanks

Hi All, Instead of using embedded asm ( __asm), how could I write a arm64.s file and integrate to a command line test project with c files ? #include &lt;stdio.h&gt; extern int myadd(int a, int b); int main(int argc, const char * argv[]) { // insert code here... printf("Hello, World!\n"); int r = myadd( 10 , 4); return 0; } And .s file .global myadd .p2align 2 .type myadd,%function myadd: // Function "myadd" entry point. .fnstart add r0, r0, r1 // Function arguments are in R0 and R1. Add together // and put the result in R0. bx lr // Return by branching to the address in the link // register. .fnend Error -- /Users/prokashsinha/Arm/ArmAndC/asmfunction.s:9:1: error: unknown directive .type myadd,%function ^ /Users/prokashsinha/Arm/ArmAndC/asmfunction.s:12:1: error: unknown directive .fnstart ^ /Users/prokashsinha/Arm/ArmAndC/asmfunction.s:13:5: error: invalid operand for instruction add r0, r0, r1 ^ /Users/prokashsinha/Arm/ArmAndC/asmfunction.s:15:1: error: unrecognized instruction mnemonic, did you mean: b, bcax, bl, br, sb, tbx? bx lr ^ /Users/prokashsinha/Arm/ArmAndC/asmfunction.s:17:1: error: unknown directive .fnend ^

In Xcode 15 beta 6, I found that when building visionOS apps, #if os(iOS) is no longer considered part of the project. This behavior is different from beta 1 to beta 5. Is this intentional? This change has caused third-party dependencies that use #if os(iOS) and have not yet explicitly supported visionOS to fail to compile. Is there a way to switch back to the old behavior? After all, requiring all third-party dependencies to explicitly support visionOS is quite difficult.

With these specs which XCode version can i download? will it be enough to begin IOS Development? Mac OS Catalina macbook pro 15 inch mid 2012 processor: 2.3 GHz Quad Core Intel Core i7 Memory 8GB 1600MHz DDR3 Graphics: NVIDA geforce gt 650M 512MB Intel HD Graphics 4000 1536MB Storage: 240GB Solid State SATA Drive

Hello everybody, I am a junior on iOS app development with Swift and Xcode IDE. I want to ask about the framework compatible issue. I got a framework called "RFIDBleFramework" which provided by vendor and this framework can help connecting to a RFID device and function well. After imported this framework to my project and build, I got the following error: "Failed to build module 'RFIDBleFramework'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.7.2 (swift-5.7.2-RELEASE)', while this compiler is 'Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)'). Please select a toolchain which matches the SDK." I want to know whether that means xcode for the same major, minor, and patch version of Swift(in this case, 5.7.2) still not compatible? Or I have some mistakes on import a framework? Sorry for my poor English, if there are some additional information required, I am willing to provide. Thank you for helping. My xcode version: Version 14.2 (14C18)

I'm defining a compilation condition in a SPM module that is being used by my iOS app. I'd like to be able to use the same compilation condition in my app code to determine behavior, but the condition doesn't seem to be getting set within my app. The condition is working as expected within the SPM module, just not in the iOS app that is importing the module. Package.swift excerpt target(..., swiftSettings: [.define("CONDITION", .when(configuration: .debug))] ) SPM Module #if CONDITION // Compiled and executes as expected #endif App #if CONDITION // Never compiled / triggered #endif

clang++ compilation appears to be completely broken under the latest version of macos Ventura (13.3)/Xcode (14.3)/CommandLineTools/MacOsX.sdk (13.3) This is easy to reproduce. Here's the simplest example I can come up with: Create a file named Test.cpp with the following contents: #include &lt;cstddef&gt; int main() { return 0; } Try to compile it with the following command on a command line in Terminal.app window clang++ -std=c++17 -stdlib=libc++ -g -c -o Test.o Test.cpp This should compile successfully and create the file Test.o, but instead it generates an error that appears to come from bug(s) within the SDK (Entire error response shown below) Error response: In file included from Test.cpp:4: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/cstddef:52:9: error: no member named 'nullptr_t' in the global namespace using ::nullptr_t; ~~^ 1 error generated. Unfortunately the error seems to occur early in the include chain of many headers. For example if instead of #include &lt;cstddef&gt; you use #include &lt;vector&gt; or #include &lt;list&gt; the number of errors returned increases dramatically. This has had the effect of derailing almost ALL of my C++ compilation on the latest version of Ventura -- a major problem for me, since I (and presumably many others) develop on the mac for a living. There are similar questions already posted on Stack Overflow / Stack Exchange: • https://stackoverflow.com/questions/75921280/updating-to-macos-13-3-broke-compiling-cpp • https://apple.stackexchange.com/questions/458062/unable-to-find-include-file-on-newly-updated-macosc-c/459037 I have also submitted the issue to Apple through the Feedback tool though I'm not sure this link is publicly viewable: • https://feedbackassistant.apple.com/feedback/12156695 A possible hint: Other internet research indicates that this problem may not occur when using Xcode to compile. I do not use Xcode, Visual Studio or any other IDE, so I haven't tested this. (I've always found it much quicker to operate "closer to the metal" with the command line and basic makefiles, so I haven't learned the IDEs.) I'd love it if anyone has any insights into how to fix this bug that has seemingly broken C++ development in the latest macos release. Thanks! Dave Lumieria

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 foledr 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) …

Dear community, I'm reading "Develop in Swift Fundamentals", and on page 89 it asks us to open a file from the downloaded file (page 9 - Download Student Materials link). I was running the last part of the exercise of page 89 and it seems I got stuck when trying to remove the last compile warning message: "1. Condition always evaluates to false" "Will never be executed" Please take a look at the screenshot, where you can see the whole code and context. I have tried to add a few breakpoints (rows 10 to 12) in order to see if they would get ignored but it looks like it's still there. Any idea how to remove / get rid of this compile warning message? Thanks, Rodrigo