I am in the the process of testing a C++ run-time package with XE6 and have many test cases that compile and test parts of the package as standalone code - i.e. I include unit(s) from the package separately in a test project.

The header file(s) for the unit(s) still contain the PACKAGE keywords that are required when the actual package is being built. This has never caused any problem with 32-bit packages in XE or earlier versions, and is still not a problem with 32-bit packages in XE6.

However, when building the test case in 64-bit mode, a strange thing happens. If the test case is a VCL application (with a form), then there is no problem. However, if the test case is a console application (specifying the VCL as target framework), the linker complains bitterly about multiple occurrences of the object modules from the part of the package under test.

PaulW wrote:However, when building the test case in 64-bit mode, a strange thing happens. If the test case is a VCL application (with a form), then there is no problem. However, if the test case is a console application (specifying the VCL as target framework), the linker complains bitterly about multiple occurrences of the object modules from the part of the package under test.

Where does the linker say the multiple occurrences are actually coming from? Are you including the actual package in the same project that is using the package's units directly?

First, embarassingly, I have to correct part of my previous message: the problem does occur with VCL forms applications as well as console applications (at least that makes it consistent).

Remy, in answer to your question, I am not including the package in the project--in fact I can't because it's not yet built and the process of converting it to 64-bit is turning out to be long and frustrating. So, what is included in a typical console application test project is the main unit of the test plus one unit borrowed from the package project. In addition, the main unit of the test includes the header file for the unit from the package project.

An example of the messages from the 64-bit linker are (there are an awful lot of these, so I have only included three):

The 32-bit compiler (and another compiler on Windows plus one on another platform I have used, are quite happy with this, but to get it past the XE6 64-bit compiler, I have to change the references in the derived class to

It looks like the problem with the duplicate object files may only be occurring with template classes, although I am not completely certain of this yet.

The units from the package are defining a non-template base class plus template classes derived from the base (and in some cases further template classes derived from the "level one" template class(es)).

The non-template base class contains methods that are independent of the actual type specified in the derived template classes, although it may call virtual functions in those derived classes.

The base class is declared with PACKAGE specified.

The derived template classes are not declared with PACKAGE specified, my reasoning being that since the templates are instanciated at the time of compiling an application that uses the run time package and not when the run-time package is built, they should not be declared as PACKAGE classes. Perhaps this is wrong.

I think I may have found the answer to my problem of duplicate object files.

Public symbol 'x' defined in both module A and B[ilink64 Error] Error: Public symbol 'triplet::sum' defined in both module C:\USERS\WIN764\NODES.O and C:\USERS\WIN764\UNIT1.OStatic data members should be declared in a header, and defined only once in a source file (not the header).

It is not only objecting to my inline function GetData(), but also to the default ctor, copy ctor, assignment operator and dtor. So, I updated the Test class, adding definitions for the default ctor, etc, and moved the inline function back into the class body:

After this, 32-bit worked, but gave me warning messages about inline functions in the package, while 64-bit worked without any warning messages.

Unfortunately, you cannot always move the inline functions into the class block. If the function body refers to another class which is defined later in the header file, then the normal answer is to define the function in the header file, with an 'inline' specifier after both class definitions.

So, sigh, the solution is to move the inline functions from the class header file to the class cpp file (removing the inline specifier). It's a pity; inlining very small functions should be good for performance.

I upgraded from X4 to Berlin.Most of my projects build fine without any problem in 64 bit setting.But some DLL-projects compiles fine, but the linker throws error like this:

[ilink64 error] error: unresolved external 'vcl::forms::application.

I hope that I find source of this error:if your project not include visual object (like TForm), compiler not linked run-time VCLlibrary needed for use methods and objects from this visual object (like Application->Exename etc).It's true for DLL- and console projects.

I try two methods for correct tis error:First method: By any text editor find in project file *.cbproj line . <FrameworkType> None </FrameworkType>

and change it to:

<FrameworkType>VCL</FrameworkType>

After that compiler include all needed run-time VCL library (rtl.lib) and project linked without errors.