Packaging Components Or Libraries Written In Classic and Clang C++ Win32 Compilers

From RAD Studio
Jump to: navigation, search

Go Up to Component Writer's Guide Index

Go Up to Working with Packages and Components Index


Objects built with the two Win32 compilers, Classic (bcc32) and Clang-enhanced (bcc32c/x), are not compatible. They are binary incompatible. Attempting to link binaries or objects, such as an executable and a static library, built with different compilers together can result in a number of errors, either at link-time or runtime. The linker attempts to detect this situation and will give a warning message.

Keep in mind, developers should not link Classic-compiled code against Clang-compiled code and vice versa. If you are a library vendor, you need to distribute two versions of your library binary for Win32. If you are an application developer, you need to ensure all libraries that are linked together are built with the same compiler.

Both Classic and Clang are compatible with Delphi-produced object files for Win32; however, Classic and Clang are not compatible with each other.

Error Messages Indicating a Compiler Mismatch

  • When different compilers used for object files that are being linked together, the linker will emit the following warning:
Warning: Compiler mismatch. Module ‘foo.lib|bar’ built with the [classic|clang-based] compiler; expected the [clang-based|classic] compiler because of ‘xyzzy.obj’

For example:

Warning: Compiler mismatch. Module ‘foo.lib|bar’ built with the classic compiler; expected the clang-based compiler because of ‘xyzzy.obj’

This warning is saying that the object file 'bar' contained in the library 'foo.lib' was built with an unexpected (in this case the Classic) compiler. The linker expected the Clang compiler because of an object file it had already processed, xyzzy.obj.

Note: There is no way to specify to the linker which compiler you expect to have been used to generate the object files you are linking. Instead, the linker will look at the compiler marker it finds in the first object it sees when linking, and the flag if it finds any objects that differ.

Error Messages before C+Builder 10.3.3

In earlier versions of CBuilder before linker compiler detection was added in C+Builder 10.3.3, the following error messages typically indicated a compiler mismatch.

  • When an app built with the Clang toolchain is linked against a Classic-built library, you may see the following errors:
[ilink32 Error] Error: Unresolved external '__InitExceptBlockLDTC'
[ilink32 Error] Error: Unresolved external '_ThrowExceptionLDTC'
Error: Unresolved external '_CatchCleanup()'
  • When an app built with the Classic toolchain is linked against a Clang-built library, you may see the following errors:
Error: Unresolved external '___seh_personality_v0'
Error: Unresolved external '__Unwind_SjLj_Register'
Error: Unresolved external 'std::_Xbad_alloc()'
Error: Unresolved external '___cxa_begin_catch'
Error: Unresolved external '___cxa_rethrow'
Error: Unresolved external '___cxa_end_catch'
Error: Unresolved external '__Unwind_SjLj_Unregister'
Error: Unresolved external '__Unwind_Resume'
Error: Unresolved external '___cpp_terminate'

Using Clang or Classic Binaries for Application Developers

If you are building an application, ensure that all binaries that are linked together are built with either the Clang-enhanced or Classic compilers, but not a mix.

If you successfully link ignoring the warning message above, your application may encounter runtime errors

Providing Clang and Classic Binaries for Component and Library Vendors

Please follow the steps:

  • Create two packages or libraries: one compiled with Classic and one compiled with Clang.
  • The Classic package goes into lib\win32[debug|release] folder.
  • The Clang package goes into lib\win32c[debug|release] folder (note the C).
  • The packages must have the same names.
  • The Classic toolchain always looks in lib\win32. The Clang one looks in lib\win32c and then lib\win32. That means it will always find the Clang version of the package first (this is why both must have the same name), but if it does not, it will find the Classic version, and then there will be errors.

See Also