Post not yet marked as solved
There's a question involving the same symbol at https://developer.apple.com/forums/thread/121260. From one of the answers there: Yeah one of the LLVM headers (api-breaking.h) had an extern int that was apparently coming from the linkage to the runtime. We replaced that with a local variable and the review process is fine now. Thanks! @cjserio The file is abi-breaking.h rather than api-breaking.h though. You may be able to progress further by doing the same thing but you might then run into the issues Developer Tools Engineer is referring to.
Post not yet marked as solved
Hi! Thanks for the reply. Today I tried creating a stand alone DummyViewController that isn't used anywhere in the app. Compiled, then add one line of code. The incremental compile time is 1 minute. At this point, I think there's something else other than the modified file here that ramps up the incremental compile time. So I dive into the build logs. I added -driver-show-incremental and -driver-show-job-lifecycle in Other Swift flags and checks the build log under Compile Swift source files. Here I attached the first 500 lines of the log. [Log] Compile Swift source files - https://developer.apple.com/forums/content/attachment/a0e7e1b3-4435-4071-a3f7-338f03a4508f Honestly, I cannot make much sense from the log above. Some help is appreciated. My best guess is that, since I see Viki-Bridging-Header.h in the log, I guess it's the bridging header. It contains some models, constants, a view controller, and some NSObject helper that is used in many places throughout the app. Is this plausible? My bridging header l
Post not yet marked as solved
Our app has 72k lines of Swift code in 922 files and 500+ lines of Obj-C code. Our clean build time is about 4 minutes. When changing code in a very minor way, e.g. adding a line in a view controller, our incremental build time is about 2-3 minutes. Which is a lot. We have done many optimizations such as warn-long-expression-type-checking, decrease file size, avoid declaring many types in one file, and reduce 3rd party dependencies. We were able to shave off only about 20 seconds. Which is not very satisfying for me. One thing we are exploring is modularize the code. We tried pulling out our core models code as a Swift Package, which contains like 20-30 types. But our incremental build time doesn't improve in anyway. Is there anything else we can do to improve incremental build time with such a large code base? Will these things works? modularize more parts of the app use binary framework instead of source code framework anything else Below is output of cloc App/. command to show more insights of our code bas
Post not yet marked as solved
I was also looking for answers for some of these questions. Specifically, I was trying to compile and use Infer analyzer tool (https://github.com/facebook/infer) - Infer uses some custom clang compiler for C++ analysis. Compiling custom clang plugin on M1 wasn't successful - there was some linking issue with LLVM. What does Facebook support say when you submitted the issue for this problem? An important thing to mention is that Infer requires some dependencies from Xcode 11.5 (there are issues with more recent versions). What does Facebook support say when you submitted the issue for these issues? I am not sure how to debug this kind of issue. Do you work for Facebook? The project is open source, so you are free to say yes whether or not you are a Facebook employee. Debugging these issues is straightforward. Install the latest versions of LLVM and other dependencies with Apple Silicon support. Correct any errors. Build infer and correct any errors that you encounter. Test using the (hopefully) supplied testin
Post not yet marked as solved
Open-source support for Apple Silicon is mainly held back by GCC’s (the GNU Compiler Collection) lack of support for the architecture. There are work progressing, but as with all open source, that would be in a “time available” basis. Likewise Docker support is progressing, but again there is no timeline. Moreover if you’re depending on x86 Docker images, you would likely need to wait longer for it to provide Intel emulation. Since Rosetta 2 does not support virtualizing x86 systems, Parallels and VMWare would also need to come up with their own emulation software to support running Intel operating systems on Apple Silicon hardware. If you really need to run x86 Docker images, a good alternative would be to buy an Intel Compute stick (a ~$100 USB-powered computer) and install Linux on it. Then you could ssh into the machine to do “Linux stuff” (including testing your server software) and run x86 Docker images. Yet keep most of your tools on the Mac. You could also set up a Terminal profile to run command-line
Post not yet marked as solved
I have a sample code to test c++ virtual deconstructor like below: #include class CA { public: virtual ~CA() { std::cout<< ~CA << std::endl; } }; class CB :public CA { public: virtual ~CB() { std::cout<< ~CB << std::endl; } }; int main(int argc, const char * argv[]) { CA *pb = new CB[3]; delete []pb; return 0; } in xcode this code print out result is : ~CA ~CA ~CA but in other compilers like visual studio C++ and gcc the print out result is: ~CB ~CA ~CB ~CA ~CB ~CA I think this is a dynamic delete array object with virtual deconstructor bug in xcode compiler 。 because the print result is not conform to C++ form。
Post not yet marked as solved
@fanick did you find any way out?
Post not yet marked as solved
I'm writing a simple Command line application on macOS with code using C++, using a API called 'std::to_chars' from charconv void foo(void) { if (__builtin_available(macOS 10.15, *)) { char buffer[10]; std::to_chars_result tcr = std::to_chars( buffer, buffer+5, 5 ); #pragma unused (tcr) }else{ return; } } Since Xcode complains main.cpp:19:41: error build: 'to_chars' is unavailable: introduced in macOS 10.15 I wrapped the code with an availability check API in C++, __builtin_available(macOS 10.15, *)) But even with this availability check API, Xcode still failed to compile. Anyone knows why?
Post not yet marked as solved
As you may know libc++ on MacOS is using weird implementation of RTTI: it compares typeinfo objects by pointers instead of comparing name-strings (like it happens in standard runtimes on Windows and Linux). Since each module has its own typeinfo instance - dynamic_cast for polymorphic types and exception handling may not work across module boundaries if you use -fvisibility=hidden and/or two-level namespace (At the runtime you will either get error from dynamic_cast, or fail to catch exception that was thrown from another module). The problem is that sometimes we have ODR violations because of legacy code, and sometimes there are reasons to legally violate ODR and define same typeinfo in multiple modules - templated polymorphic type. To make polymorphic types work across modules we must make sure that our typeinfo symbols are coalesced (merged) across these modules. This is why I started investigating the way symbols are coalesced on MacOS, my observations so far: For dylib compiled with -flat_namespace every
Post not yet marked as solved
@eskimo Please update your macOS and try again.
Post not yet marked as solved
Currently in Xcode 13, clang static analyzer is not analyzing Swift Language. Will Clang Static Analyzer eventually support Swift Language in the upcoming releases?
Post not yet marked as solved
I am working with a big project event is take 40 minutes to generate dSYM file. Is there any way I can replace the dsymutil with custom version.
Post not yet marked as solved
Hi there, since upgrading to the latest Xcode and Command Line Tools, I get the follwoing error when compiling: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__iterator/wrap_iter.h:133:13: error: arithmetic on a pointer to an incomplete type 'Xstring' __i += __n; ~~~ ^ Does anyone has an idea, how to overcome this , is there a compiler flag which I am missing ? Thanks a lot Best Hannes. PS: here is the full compilation and error: g++ -DPACKAGE_NAME=xfitter -DPACKAGE_TARNAME=xfitter -DPACKAGE_VERSION=VERSION_NUMBER -DPACKAGE_STRING=xfitter VERSION_NUMBER -DPACKAGE_BUGREPORT= -DPACKAGE_URL= -DPACKAGE=xfitter -DVERSION=VERSION_NUMBER -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=.libs/ -DFC_FUNC(name,NAME)=name ## _ -DFC_FUNC_(name,NAME)=name ## _ -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLA
Post not yet marked as solved
Source code: #include static const char encodeBase64Table[64 + 1] = ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/; int main() { // create decoding table unsigned long invalid = 64; unsigned long decodeBase64Table[256] = {}; for (unsigned long i = 0; i < 256; i++) decodeBase64Table[i] = invalid; for (unsigned long i = 0; i < 64; i++) { decodeBase64Table[(unsigned char)encodeBase64Table[i]] = i; } printf(decodeBase64Table[65] = %lun, decodeBase64Table[65]); return 0; } Apple Clang 11.0.3 (expected output, even with -O3): /t/s/1673994196 ❯❯❯ /usr/bin/clang++ --version Apple clang version 11.0.3 (clang-1103.0.32.62) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin /t/s/1673994196 ❯❯❯ /usr/bin/clang++ -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -O3 a.cpp /t/s/1673994196 ❯❯❯ ./a.out decodeBase64Table[65] = 0 Apple Clang 14.0.0 (unexpected output, only with -O3): /t/s/1673994196 ❯❯❯ /Applications/Xcode.app
Post not yet marked as solved
Hello everyone. I've been dealing with this issue for over a month on my M1 MBP. I'm using CLion for C++. I cannot get any program I write to compile with g++/gcc. I have taken the following steps to remedy the issue: Update CLion, Reinstall CLion, Update and Reinstall CommandLineTools, Reinstall MacOS, reset the computer to default. I've tried everything I can think of to get this to behave how it was originally. The issue started when I updated to MacOS Ventura. I deeply, deeply regret upgrading at this point but have no way of going back. This is a very basic program I've written to demonstrate the issue. int main() { welcome(); } void welcome(){ std::cout << Hello world; } void welcome(); Very, very basic. The issue is that every single time I try to do g++ main.cpp, I get the following error. welcome(), referenced from: _main in main-fbb48c.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
