Question

We are trying to split up our monolithic EXE into a combination of an EXE and several packages. So far, we have one package that we’re trying to use, and when running the EXE Codeguard shows the following error on startup:

CG Error

Two different CRTLDLLs are loaded. CG might report false errors
(C:\Windows\system32\CC32100MT.DLL)
(D:\Projects\Foo\Bar.bpl)

OK   

I read this as two different runtime libraries being loaded – one, the correct one (CC32100MT.dll), one incorrect, which is the package we’re trying to use.

Continuing to run the program shows odd errors, especially casting between classes or passing a pointer to a class as a parameter in a method that crosses the EXE/DLL boundary. Codeguard itself doesn’t show any other errors at all though. Edit: This is now resolved, and wasn’t related. The program appears to run correctly, but the warning Codeguard shows is still worrying.

How do we solve this?

Some more details

We’ve looked at as many things as we (the developer working on this and I) can collectively think of:

• Each project is built using runtime packages. The EXE host lists Bar in its package list.

• Each project is set to compile with dynamic RTL. However, changing this does not solve the problem.

• The package is linked to the EXE via its BPI file, but linking via a LIB makes no difference either.

• The EXE and BPL are compiled with the same project settings, where the same options exist for both types of project. We think, anyway 🙂

• There is only one copy of the BPL and BPI on the system: it’s definitely linking to the right one.

• Examining the EXE and BPL with Depends and TDump show they are both using C:\Windows\system32\CC32100MT.DLL. They should both be using the one RTL.

• Creating a new project (a plain VCL forms application) and linking to the BPL (via its BPI) works fine. Something in the process of adding all the files and LIBs that make our EXE contain the code it needs to changes this, but we haven’t been able to figure out what.

  • The LIBs all either correspond to DLLs we use (flat C interface, usually look as though they were built with MSVC) or are simple projects with lots of related files, compiled to a lib for the purpose of linking into the EXE – these correspond roughly to the areas of the program we want to split to BPLs, by the way. There don’t seem to be project options for the LIB projects that would affect RTL linking, unless we’ve missed them.

  • I have exhaustively hunted through Depends and looked at all RTL and CC32*.dll files the EXE and every single DLL references. All are identical: rtl140.bpl and CC32100MT.DLL. Fully qualified paths show they are the same files, too. Everything should be using the one same run-time library.

Edit: The final EXE is complex, built with several libs, several DLLs, etc. All these, when built with C++Builder, are built with the current version. Is it possible there’s something in one of these DLLs or LIBs that could cause a problem? I don’t know enough about how the RTL is linked in to be sure about where to look… my (naive?) assumption is that the linker would normally link in one set of RTL functions, but that of course doesn’t seem to be happening… and I don’t know how things change when using packages. Is it possible this error has always existed and Codeguard has not flagged it before, because we haven’t used something dynamic like a package?

Perhaps another question is, Why would a package have its own RTL anyway, or what would make it count as ‘a RTL DLL’ to Codeguard?

We’re stumped. Absolutely stumped. We’ve had other problems using BPLs (they seem to be surprisingly tricky things, especially using C++) but have managed to solve them all. This one we’ve had no luck at all and we’d really appreciate any insights 🙂

We’re using C++Builder 2010 (as part of RAD Studio actually, but with little Delphi code apart from components.)

Edit: Started a bounty. I’d really like to solve this!

Edit 2: Thanks to David Dean for his help (marked as answered below.) Via email, he pointed out this issue was reproduced in a simple test case by someone else, and is logged in Embarcadero QC as report 86335. Currently there is no fix, but the warning does not appear to indicate a genuine problem (ie, it’s probably a spurious error, and while it’s a pity to have to click past the dialog when you run, hopefully there’s nothing in the error to worry about.)

Answer 1

Since one of these is coming from a .bpl, did you try turning off “Build with runtime packages” in the project options?