Troubleshooting the bcc64x (Win64 Modern) Toolchain
Go Up to C++Builder 64-bit Windows (Modern) Application Development
The following are some common potential issues.
Contents
Unexpected access violations in release-mode applications
The newer Clang and LLVM are more strict about undefined behavior (UB). One common class of undefined behavior is an uninitialized variable, where the variable value can be effectively random.
In the past, this would compile, and your program might appear to work.
In newer versions of Clang, when optimizations are on (which is when LLVM is more strict about UB because doing so lets it make more optimizations), when an uninitialized variable is used, LLVM inserts a trap instruction. This manifests at runtime as a crash.
To resolve this, build with -Wuninitialized and resolve each warning by ensuring each variable is always initialized.
-Wall by default and resolving all compiler warnings.Crash, where memory is 0x80 bytes
The UCRT memory manager fills freed memory with values of 0x80.
If you see a crash and the memory being accessed is filled with this value (e.g., 0x80808080), this indicates that the memory has been freed. To resolve this, track down the cause of accessing this memory location/object/pointer after it’s been freed.
Slow compilation time
bcc64x should have approximately the same compile speed as previous Clang compilers. One common issue is the number of warnings the compiler emits: the more warnings, the slower it gets.
We recommend fixing warnings because they often correctly indicate potential issues.
You can also disable specific warnings with #pragma clang diagnostic ignored "-Wfoo" to disable the “foo” warning.
We also recommend using TwineCompile for parallel compilation, which is available in GetIt Package Manager for customers active on maintenance.
Duplicate Symbols when building with bcc64x on the command line
When compiling directly with bcc64x and ld.lld, instead of using msbuild or IDE, you may see errors about duplicate symbols.
Duplicate symbols are traditionally treated as errors in C++ by default, but when linked with Delphi, some duplicates are expected, which can be inconvenient. Because of this, the IDE and msbuild compilations already ignore this error by default.
To allow duplicate symbols, the -Xlinker --allow-multiple-definition flag must be added to the bcc64x command line, transforming them into warnings.
To allow duplicate symbols without displaying a warning for them, you must add the flags -Xlinker --allow-multiple-definition -Xlinker --Wno-multiple-definition to the bcc64x command line.
Compile results not in sync with the code editor
The IDE provides a virtual file system, which allows new or modified files to be compiled with the contents in-editor rather than saved on disk. Our integration of the Clang 15-based toolchain uses a different mechanism to the one used in the IDE in the past to represent the VFS (called VFS overlay, a clang feature), storing files temporarily on disk with a different filename when compiling, with the compiler and linker mapping the filename it’s looking for to the temporary file.
While there are no known bugs, you can retain the temporary files to verify the contents of what is being compiled and diagnose any inconsistencies between what you see in the editor or form designer (also text and linked in) and the compiled app.
To do this, go to Project Options > Building > C++ Compiler > Advanced, and turn off ‘Remove temporary VFS files after compilation’.
The command line in the compiler output shown in the Messages view lets you see which files are compiled and which filenames to check.