I have an old iOS project that I'm updating.It uses UIAlertView a lot, which was deprecated in iOS 9, but I'm not seeing any deprecation warnings when I build the app.(I've seen warnings when updating other apps.)This is concerning me. If I'm not seeing these warnings, what other warnings am I missing?I've checked the build settings for the app and under "Apple LLVM 8.1 - Warnings - All languages" the setting for "Deprecated Functions" is set to "Yes" as it seems like it should be.I've grepped my entire project for the words "deprecate" and "warning" and "pragma" and nothing's showing up that would suppress these warnings.Does anybody have any advice for other things to check? Thanks in advance! (BTW, I'm using XCode 8.3.3 8E3004b.)

I've got an iOS framework that I've had around for ages. It's a mixture of Objective-C and Swift. Since installing Xcode 12, I'm now getting a bunch of warnings of the type: 'Double-quoted include in framework header, expected angle-bracketed instead' If I go to the various source files and say change: #import "Place.h" to #import <VegasKit/Place.h> then I get an error saying it can't find the file. If I try this: #import <Place.h> then I get an error telling me to go back to double-quotes, i.e. undo the change. Any idea what I can do to get this all setup correctly? Thanks.

I use clang 12 to build some cpp project that needs semaphore.acquire() function. System version: MacOs Big Sur 12.0 However, Compiler shows that some function is unavailable. Detail messages: /concurrencpp/source/executors/worker_thread_executor.cpp:42:21: error: 'acquire' is unavailable [build] m_semaphore.acquire(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:202:10: note: 'acquire' has been explicitly marked unavailable here [build] void acquire() [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:106:21: error: 'release' is unavailable [build] m_semaphore.release(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here [build] void release(ptrdiff_t __update = 1) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:121:21: error: 'release' is unavailable [build] m_semaphore.release(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here [build] void release(ptrdiff_t __update = 1) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/worker_thread_executor.cpp:160:17: error: 'release' is unavailable [build] m_semaphore.release(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here [build] void release(ptrdiff_t __update = 1) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:218:26: error: 'try_acquire_until' is unavailable [build] if (!m_semaphore.try_acquire_until(deadline)) { [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:219:10: note: 'try_acquire_until' has been explicitly marked unavailable here [build] bool try_acquire_until(chrono::time_point<Clock, Duration> const& __abs_time) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:218:26: error: 'try_acquire_until<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1, 1000000000>>>' is unavailable [build] if (!m_semaphore.try_acquire_until(deadline)) { [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:219:10: note: 'try_acquire_until<std::__1::chrono::steady_clock, std::__1::chrono::duration<long long, std::__1::ratio<1, 1000000000>>>' has been explicitly marked unavailable here [build] bool try_acquire_until(chrono::time_point<Clock, Duration> const& __abs_time) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:322:25: error: 'release' is unavailable [build] m_semaphore.release(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here [build] void release(ptrdiff_t __update = 1) [build] ^ [build] /Users/mirocos/master/study/concurrencpp/source/executors/thread_pool_executor.cpp:420:17: error: 'release' is unavailable [build] m_semaphore.release(); [build] ^ [build] /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/semaphore:197:10: note: 'release' has been explicitly marked unavailable here [build] void release(ptrdiff_t __update = 1) [build] ^ [build] 4 errors generated. can anyone could help me with it?

Hi, What could be causing this on Monterey (M1 Max)? How to debug further? Reproduction steps filed in https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/301 0 0x104768224 __assert_rtn + 128 1 0x10476e4e8 ld::tool::OutputFile::addDyldInfo(ld::Internal&, ld::Internal::FinalSection*, ld::Atom const*, ld::Fixup*, ld::Fixup*, ld::Fixup*, ld::Atom const*, ld::Atom const*, unsigned long long, unsigned long long) (.cold.1) + 0 2 0x1046b0b98 ld::tool::OutputFile::addDyldInfo(ld::Internal&, ld::Internal::FinalSection*, ld::Atom const*, ld::Fixup*, ld::Fixup*, ld::Fixup*, ld::Atom const*, ld::Atom const*, unsigned long long, unsigned long long) + 0 3 0x1046a3544 ld::tool::OutputFile::generateLinkEditInfo(ld::Internal&) + 1188 4 0x10469da90 ld::tool::OutputFile::write(ld::Internal&) + 140 5 0x10462b1d8 main + 584 A linker snapshot was created at: /tmp/libHSfuturice-integrations-0-inplace-ghc8.10.7.dylib-2022-00-08-222023.ld-snapshot ld: Assertion failed: (target->definition() != ld::Atom::definitionProxy), function addChainedFixupLocation, file OutputFile.cpp, line 5903. clang-12: error: linker command failed with exit code 1 (use -v to see invocation) `clang' failed in phase `Linker'. (Exit code: 1)

Lately we have added swift code to our SDK. (especially swiftUI library). The SDK deployment target is ios9. While importing the SDK to the hosting app with the same deployment target and building via Xcode (13.4) everything works fine. When we try to build it via xcodebuild (xcodebuild -workspace UIKitCatalog.xcworkspace -scheme UIKitCatalog -sdk "iphonesimulator") the build is done successfully but the the app is crashing on app lunch (sim and device) . Increasing the deployment target of the hosting app to iOS 13 fixes the issue (unfortunately we cant force our customers to do the same) CrashReporter Key: 74B25560-EFCE-769F-F0B4-E4DD4C6B09A4 Hardware Model: MacBookPro15,1 Process: UIKitCatalog [63980] Path: /Users/USER/Library/Developer/CoreSimulator/Devices/F044CBD3-80D6-49FB-BAC9-FA48FA3CFF7E/data/Containers/Bundle/Application/72290230-2DB3-4F75-8327-75B6E4E9947C/UIKitCatalog.app/UIKitCatalog Identifier: ba.UIKitCatalog Version: 2.0.0.23386 (23386) Code Type: X86-64 (Native) Role: Foreground Parent Process: launchd_sim [56632] Coalition: com.apple.CoreSimulator.SimDevice.F044CBD3-80D6-49FB-BAC9-FA48FA3CFF7E [10638] Responsible Process: SimulatorTrampoline [2048] Date/Time: 2022-08-29 11:59:21.3026 +0300 Launch Time: 2022-08-29 11:59:19.9381 +0300 OS Version: macOS 12.5.1 (21G83) Release Type: User Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fff7017300e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff701cb1ff pthread_kill + 263 2 libsystem_c.dylib 0x7fff2010b6b7 abort + 130 3 libswiftCore.dylib 0x10e7c0af5 swift::fatalError(unsigned int, char const*, ...) + 149 4 libswiftCore.dylib 0x10e7b86ec checkVersion() + 44 5 dyld_sim 0x10d0689f7 invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 182 6 dyld_sim 0x10d0850f5 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 129 7 dyld_sim 0x10d07e58c invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 555 8 dyld_sim 0x10d07d6e9 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 129 9 dyld_sim 0x10d07e31f dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 179 10 dyld_sim 0x10d084b56 dyld3::MachOAnalyzer::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, unsigned char const*, bool&) block_pointer) const + 118 11 dyld_sim 0x10d084d98 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 386 12 dyld_sim 0x10d06892a dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 144 13 dyld_sim 0x10d068ac2 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 190 14 dyld_sim 0x10d068aa5 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 161 15 dyld_sim 0x10d068aa5 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 161 16 dyld_sim 0x10d068b60 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 102 17 dyld_sim 0x10d077b5a dyld4::APIs::runAllInitializersForMain() + 222 18 dyld_sim 0x10d05b9fe dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2528 19 dyld_sim 0x10d05be42 _dyld_sim_prepare + 379 20 dyld 0x110e6eb78 dyld4::prepareSim(dyld4::RuntimeState&, char const*) + 1265 21 dyld 0x110e6d70e dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 244 22 dyld 0x110e6d4e4 start + 388 How can we overcome this issue? What Xcode is doing under the hood that xcodebuild doesnt do? Is it possible to release an SDK which import swiftUI but will have deployment target lower than 13. (I have wrapped all the the swift code with @available() and #if canImport(SwiftUI) - less relevant as its compile time )

Our Kotlin MPP code which compiled/linked fine using Xcode 15 Beta 2 no longer links using Xcode 15 Beta 3: ld: unknown options: -ios_simulator_version_min -sdk_version Is the option ios_simulator_version_min removed/renamed? (Intentionally?) Should Apple or JetBrains fix this? (also reported to JetBrains as KT-60238).

Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace. Stack dump: 0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend -frontend -c /Users/lawrey/Documents/GitHub/IPPTPLUS-IOS/IPPT/Common/Toast/Toast.swift /Users/lawrey/Documents/GitHub/IPPTPLUS-IOS/IPPT/Shop/CheckOutViewController.swift /Users/lawrey/Documents/GitHub/IPPTPLUS-IOS/IPPT/Common/UITextField/NLPaddedTextFieldView.swift ... ... /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/SettingsVC.o -index-unit-output-path /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/DGElasticPullToRefreshConstants.o -index-unit-output-path /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/DGElasticPullToRefreshView.o -index-unit-output-path /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/CountDownRouterVC.o -index-unit-output-path /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/DatePickerTableViewCell.o -index-unit-output-path /IPPT.build/Release-iphoneos/IPPT.build/Objects-normal/arm64/CircularProgress.o 1. Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100) 2. Compiling with the current language version 3. While evaluating request ExecuteSILPipelineRequest(Run pipelines { PrepareOptimizationPasses, EarlyModulePasses, HighLevel,Function+EarlyLoopOpt, HighLevel,Module+StackPromote, MidLevel,Function, ClosureSpecialize, LowLevel,Function, LateLoopOpt, SIL Debug Info Generator } on SIL for IPPT) 4. While running pass #670343 SILModuleTransform "DeadFunctionAndGlobalElimination". Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 swift-frontend 0x0000000109b7f300 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) + 56 1 swift-frontend 0x0000000109b7e2e4 llvm::sys::RunSignalHandlers() + 112 2 swift-frontend 0x0000000109b7f910 SignalHandler(int) + 344 3 libsystem_platform.dylib 0x000000019418aa24 _sigtramp + 56 4 swift-frontend 0x00000001052bb65c (anonymous namespace)::DeadFunctionAndGlobalEliminationPass::run() + 424 5 swift-frontend 0x00000001052bb65c (anonymous namespace)::DeadFunctionAndGlobalEliminationPass::run() + 424 6 swift-frontend 0x00000001054214a0 swift::SILPassManager::executePassPipelinePlan(swift::SILPassPipelinePlan const&amp;) + 15312 7 swift-frontend 0x0000000105442a04 swift::SimpleRequest&lt;swift::ExecuteSILPipelineRequest, std::__1::tuple&lt;&gt; (swift::SILPipelineExecutionDescriptor), (swift::RequestFlags)1&gt;::evaluateRequest(swift::ExecuteSILPipelineRequest const&amp;, swift::Evaluator&amp;) + 56 8 swift-frontend 0x0000000105428dd4 llvm::Expected&lt;swift::ExecuteSILPipelineRequest::OutputType&gt; swift::Evaluator::getResultUncached&lt;swift::ExecuteSILPipelineRequest&gt;(swift::ExecuteSILPipelineRequest const&amp;) + 484 9 swift-frontend 0x000000010542b714 swift::runSILOptimizationPasses(swift::SILModule&amp;) + 400 10 swift-frontend 0x0000000104c09c10 swift::CompilerInstance::performSILProcessing(swift::SILModule*) + 524 11 swift-frontend 0x0000000104a6d51c performCompileStepsPostSILGen(swift::CompilerInstance&amp;, std::__1::unique_ptr&lt;swift::SILModule, std::__1::default_delete&lt;swift::SILModule&gt; &gt;, llvm::PointerUnion&lt;swift::ModuleDecl*, swift::SourceFile*&gt;, swift::PrimarySpecificPaths const&amp;, int&amp;, swift::FrontendObserver*) + 1040 12 swift-frontend 0x0000000104a70ab8 performCompile(swift::CompilerInstance&amp;, int&amp;, swift::FrontendObserver*) + 3288 13 swift-frontend 0x0000000104a6e944 swift::performFrontend(llvm::ArrayRef&lt;char const*&gt;, char const*, void*, swift::FrontendObserver*) + 4308 14 swift-frontend 0x0000000104a3368c swift::mainEntry(int, char const**) + 4116 15 dyld 0x0000000193e03f28 start + 2236 Command SwiftCompile failed with a nonzero exit code I need help understanding the root cause to resolve. Overwhelmed by the log :(

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

Hi All, I am using Xcode 15. I am trying to change the compiler in XCode to use the version of clang++ installed at /opt/homebrew/Cellar/llvm@14/14.0.6/bin/clang-14 However, when I set the compiler under Build Options > Compiler for C/C++/... It gives me an Unsupported Compiler Warning, and from the build messages, it looks like it is defaulting back to Apple's version of Clang. Is there something I am missing here? Are there additional steps required to get this to work? Thank you kindly in advance.

On Ventura 13.5.2 (22G91), Macbook pro 13 2019 (Intel): The following combination of the C code and Assembly code fails to link conftest_c.c: //conftest_c.c: #ifdef __cplusplus extern "C" { #endif void gsym_test_func(void); #ifdef __cplusplus } #endif int main() { gsym_test_func(); return 0; } Obj compiled using the command clang -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -mcx16 -I. conftest_c.c -c produces conftest_c.o That exposes the following symbols: SYMBOL TABLE: 0000000000000000 g F __TEXT,__text _main 0000000000000000 *UND* _gsym_test_func Now we create assembly conftest.s that define _gsym_test_func: .text # _gsym_test_func .globl _gsym_test_func _gsym_test_func: # _gsym_test_func with the objdumb symbols: SYMBOL TABLE: 0000000000000000 g F __TEXT,__text _gsym_test_func Trying to link the two object files into a binary using the following command clang -O3 -DNDEBUG -v -finline-functions -fno-strict-aliasing -mcx16 conftest_c.o conftest.o -o conftest -lz results in the following error: Apple clang version 15.0.0 (clang-1500.0.40.1) Target: x86_64-apple-darwin22.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 13.0.0 14.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -O3 -o conftest -L/usr/local/lib conftest_c.o conftest.o -lz -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a ld: Undefined symbols: _gsym_test_func, referenced from: _main in conftest_c.o clang: error: linker command failed with exit code 1 (use -v to see invocation) I do not understand why the linker cannot find the symbol _gsym_test_func defined in conftest.o

I can't use openmp with Xcode 15.0

After upgrading my Xcode from 14.3 to 15.0, there is a compilation error "Unsupported mach-o filetype (only MH_OBJECT and MH_DYLIB can be linked) in libLLVM.dylib". There is no solution found anywhere (Google, Stackoverflow, This forum). The error message is not helpful to locate the root cause. I also tried to read through this page https://iphonedev.wiki/Mach-O_File_Format to know more about LLVM, MH_OBJECT. So far, i cannot find any good reference.

ld_prime of Xcode 15 produces duplicate symbols when linking a static library containing Objective-C++ object in case using the flags -ObjC and -Wl,force_load. // foo.h #pragma once int Inc(int i); // foo.mm #include "foo.h" #include <Foundation/Foundation.h> @interface Foo : NSObject @end @implementation Foo @end int Inc(int i) { return i + 1; }; // main.cpp #include "foo.h" int main(int argc, const char * argv[]) { return Inc(0); } ❯ clang++ -c foo.mm ❯ ar rcs libfoo.a foo.o ❯ clang++ -framework Foundation libfoo.a -x c++ main.cpp -Wl,-force_load,libfoo.a -ObjC duplicate symbol '__Z3Inci' in: libfoo.a[2](foo.o) libfoo.a[2](foo.o) duplicate symbol '_OBJC_CLASS_$_Foo' in: libfoo.a[2](foo.o) libfoo.a[2](foo.o) duplicate symbol '_OBJC_METACLASS_$_Foo' in: libfoo.a[2](foo.o) libfoo.a[2](foo.o) ld: 3 duplicate symbols clang: error: linker command failed with exit code 1 (use -v to see invocation)```

I just started getting lots of "redefinition of" errors with headers that start with #pragma once. The C++ clang compiler is set to "C++17". Did something change with handling #pragma?

Does this exist? Apple seems to have a unique syntax it recognizes (vs GCC arm64 assembler) and getting assembly code cross compiled it for iOS in Xcode has been very frustrating and unfruitful. Is there any guidance on how to do this? The reason for assembly is to support "volk, vector optimized library".

Hallo, I am co-author of an open source timetabling software. This software is running many years now on Windows, Linux and MacOS without crashing. So I compiled it with a lot of different compilers and it is always running fine. (with Windows mingw compiler, linux gcc compiler, ...) Now I compiled it on my new Mac and noticed and it is running fine as long as i am compiling it with -o1 or -o2 or -o3 or -ofast or -os or -oz. But as soon as I compile it with -o0, then it crashes with MacOS. It doesn't crash if I compile with -o0 under Linux gcc compiler. I tried to do a minimum example, but as soon as I remove some - in that situation unneeded - code, it is running fine again. So it looks like a memory limit in the compiler or something like that. I don't get it. Any ideas how I can locate and/or fix the bug? You can find the source here: https://lalescu.ro/liviu/fet/forum/index.php?topic=5729.0 I compiled with the latest clang version shipped with latest MacOS Sonoma. I am also attaching the crash report log. Thank you for your help. appleLog.txt.log

I used the command: utils/build-script --swift-darwin-supported-archs "$(uname -m)" --xcode --clean and encountered the following error: CMake Error at cmake/modules/SwiftUtils.cmake:24 (message): Error! Variable THIN_INPUT_TARGETS is false, empty or not set. Call Stack (most recent call first): stdlib/cmake/modules/AddSwiftStdlib.cmake:3068 (precondition) stdlib/public/libexec/swift-backtrace/CMakeLists.txt:39 (add_swift_target_executable) Please let me know the solution to this error. Thank you. Have a great day as well. 👍

I am the author of the open-source Dynace. This is an OO extension to C. It has been in production use for around 20 years. It has been used on DOS, all Windows, Linux, macOS/Intel, VMS, PLAN9, COSMIC, SUNOS, etc. all without a problem. However it does not run on Apple M1, M2 machines. I traced the problem to variadic function calls. I am creating a va_list in a ... function. I then pass the va_list to a second function. I wrote something to copy the the va_list (via va_copy) to see what I am getting. The first function works okay. But the second function does not. (I know you can't re-use a va_list.) I have spend a couple of days on this and can't find a problem with my code. I tried creating a simple example but it worked. Apparently the problem is situational. Anyway, I have no idea what is wrong or what to do next. I'd sure appreciate any help! Thanks!

Hi, I just started practicing Static Linking, and I tried to link a third party library into my code, but it kept bugging error: "The header file not found", so I believe there're some steps missing from my code, wish someone can help! Here is the situation: I use OpenGL as the target library, it contains two directories: "Include" directory which holds header files and "lib-arm64"directory which holds "libglfw3.a" and "libglfw.3.dylib". I believe .dylib is related to dynamic linking, so I am not gonna touch that and .a file is the source code I need. Therefore: In Build Phase -&gt; Linking Binary with Library, I attach "libglfw3.a". In Build Setting -&gt; Search Path, I include the address of header directory "Include" in "Header Search Path" and "lib-arm64" in "Library Search Path". "#include &lt;GLFW/glfw3.h&gt;" is the command I copied from OpenGL website template and used in my code. The error is: " 'GLFW/glfw3.h' file not found " If anyone has any advice, feel free to share it, I really appreciate! Another question I have, non-relevant to linking, but to debugging.

I'd like to use the Clang AST tools for iOS/Mac projects. I want to write C++ programs that link to the Clang libraries. I will use that to analyze the AST from my IOS/Mac projects. I understand you can generate an AST dump from Apple's Clang but I instead want the full capabilities of the Clang libraries, not just the AST output. I believe I need to build compilation databases in order for many Clang libraries to be used. For instance, l'd like to use the CommonOptionsParser which requires arguments for the compilation database. Building these compilation databases is where I'm running to challenges. Its my understanding I will need to use the same LLVM version I'm using for the tooling (open source 17.x) to also build my compilation database. I already tried to use Apple's build-in LLVM to build the database but that led to build arguments such as -index-store-path being included in the JSON, which I don't think Open source LLVM can understand (failing to build). I instead attempted to use the Open Source LLVM installation with my iOS/Mac project. I got it kind of working but am not quite there. My question is whether this approach is worth pursuing? I'm dealing a lot of build errors doing this, particularly in nested swift packages that build fine with Apple Clang. Before I try to fix all these errors, I just wanted to ask whether using Open Source LLVM to build compilation databases for iOS/Mac projects is the right high-level approach for my goals mentioned initially? Is anyone doing this for complicated projects? Another option I thought of is maybe I can "clean up" the compilation database that is generated from Apple's Clang to remove the -index-store-path arguments. Then I could use that as an input to Open Source Clang.