CODEWITHSUNDEEP
delphi
D.D
D.D

Reputation: 147

Why can I compile 64 bit Delphi libraries through runtime package but not through source?

We are just starting on migrating some of our projects to 64-bit in Delphi, we also have a couple of 3rd party Delphi libraries that we are using. Traditionally, when we use a 3rd party library we do so by using the design time package .bpl OR we just have the compiler compile the source code.

However, in 64-bit it seems we have to do it completely differently. If we are compiling a 64-bit library we need to use DCU.

For example, we have a library that we needed to use in 64-bit. The library supports 64-bit. To get it to work, I had to compile the runtime package as 64-bit then point the compiler to the outputted 64-bit DCU files. When I try to compile the library from source as 64-bit we get all kinds of errors.

So my question basically is: Why/How can we compile the source code through the runtime packages in 64-bit just fine, but when we try to compile as just source code in 64-bit we get errors?

To further illustrate just in case that wasn't clear:

A. Put all source files on search path. Compile program as 64-bit. ERRORS.

B. Open up supplied runtime .dproj from 3rd party library. Compile runtime library as 64-bit. Put outputted 64-bit DCU on search path. Compile program. Works fine.

Thanks

Edit: I'm going to be much more specific because it appears that i have failed in conveying what I'm trying to ask here.

We are using Clever Internet Suite 9.1 for Delphi. We DO NOT use the design time package when compiling in 32-bit. We link directly to the source code through Delphi's search path. This works fine.

When I change my application to build as 64-bit We get this error:

[dcc64 Error] clSocket.pas(1971): E2089 Invalid typecast

A sample of the offending code (Slightly changed):

procedure cldostuff.WndProc(var Message: TMessage);
begin
  if (Message.Msg = cl_const)
    and (clSpecialType(Message).LookupHandle = FLookupHandle) then
  begin
    syncerror:= clSpecialType(Message).syncerror;
    SetEvent(FCompleted);
  end;
end;

The error is on the casting of the TMessage. I understand why TMessage would cause an error. I am not concerned about the error. I am curious as to HOW compiling through a "package" works but not in DCU. Apparently I have misused the terminology of "Runtime package". I will post exactly what the clever developers told me on how to use in 64 bit.

The Clever Internet Suite fully supports 64-bit platform. The installer includes binaries for both 32-bit and 64-bit. Also, if you want to re-compile the library, you need to switch the platform option within the clinetsuite_x.dproj file, and recompile it (where _x depends on your Delphi version, e.g., in case of Delphi 10.3 Rio, the project file will be clinetsuite_103.dproj).

So I do Exactly that. I open up that .Dproj file and compile it. Once I do that it creates a Win64/Output folder that has ALL the dcus of the library. I can link to that and work in win64 bit just fine.

My questions is WHY does it work when I compile through the "Supplied .dproj file" but not when I compile through source code.

Hopefully I've done a better job of articulating what I am asking.

Upvotes: 0

Views: 675

Answers (1)

David Heffernan
David Heffernan

Reputation: 613013

That compiler error is typically caused by a typecast between two value types of different size. If the code works in some compilation scenarios but not others then the obvious conclusion is that the record alignment options differ in those scenarios.

Most likely the package dproj file defines aligned records, i.e. {$ALIGN ON}. But your project does not. Perhaps it uses packed alignment, {$ALIGN 1}.

Make sure that all the units in the library are compiled with the same options as specified in the package dproj file. Typically that is done by the library providing an include file that specifies desired options and then the include file is included in all units. That insulates the code from compiler options specified in the host dproj file that are incompatible with those that the code requires.

You can add such a common include file since you have the source. In the longer term you should ask the developers of the library to make their code standalone and not require external specification of critical compiler options.

Upvotes: 2

Related Questions