A.M. Hoornweg

Please try to disable "code inlining control" in the compiler settings and see if the problem disappears.

FOUND! The L902 linker error disappears if I set the compiler switch "code inlining control" to OFF! I can reproduce this in several 32-bit programs that had this problem. Kudos to my colleague Ralf Claussen who discovered this by chance.

I want "F2084 Internal Error L902" gone !!!

Hello all, I have ported a large project (32-bit, 1.4 million LOC) from Delphi 11 to Delphi 12 (enterprise). Performing a "full build" works fine, but a "make" produces linker error L902 every time; now just imagine you're debugging something and have to do a full build all the time. It's simply no fun. I have never had this problem in Delphi 11. Is there any way I can circumvent this problem ?

What are you talking about??? I'm not compressing any EXEs. I'm just preventing that 30-40% of unused stuff gets linked into them (it would be nice if Delphi's linker had such an option). And of course I use highly compressed setups.

I have *always* used installers. Nowadays executable size is not much of an issue anymore, thanks to better networks. But in a not so distant past I had to regularly push software updates to locations that were using T&T Inmarsat Mini-M satellite terminals. Imagine the slowest and most expensive connection imaginable, 2400 bps, costing like 5 euros per minute. I'm glad those days are over.

It adds up in some projects consisting of dozens of dlls and executables. I had to cope with deployment over slow connections paid by data volume until quite recently.

The problem with using UPX is the following. Normally Windows would open an executable file using a "memory mapped file" mechanism instead of bluntly allocating memory and loading the contents. This allows the Windows virtual memory manager to efficiently "page in" sections of the executable as needed (on demand paging), improving performance and minimizing memory use. If the file is compressed using UPX, execution starts in the UPX loader stub which immediately allocates a big block of memory and extracts the executable into that before proceeding with the "real" execution. This simply wastes precious resources.

I have made an application that copies the Delphi RTL/VCL source files into a temporary folder, inserts the text '{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}' in the right places and re-builds the whole lot. The compiled *.dcu files contain a lot less RTTI than before. By linking against this compacted RTL I achieve a size reduction in a 64-bit VCL application from 14 MB to 10.3 MB using Delphi 12. For just a single executable that isn't worthwhile, but I use this in some multi-module projects that consist of a few dozen ActiveX EXE's and DLL'S. There the cumulative size reduction is substantial. Proper testing is hugely important, one has to be sure that the missing RTTI doesn't cause the program to malfunction.

In that case it may have to do with the changed FPU flags behavior in Delphi 12. Try doing this right before calling your DLL, does it make a difference? SetFPUMask([exdenormalized, exunderflow, exprecision]); This setting makes the FPU behave like in previous Delphi versions. In other words, a FP division by 0 will generate an exception instead of continuing the code path with a NAN result.

Please verify if "sizeof (tViewerParams)" gives the same result in all compilers. Also, is the calling convention to the dll function declared identically and clearly in all projects (e.g. "stdcall") ?

The thing that may bite you here is field alignment. The compiler that created the DLL and the compiler that created the *.exe must use identical settings for field alignment so they expect the members of the record at identical offsets. see https://docwiki.embarcadero.com/RADStudio/Athens/en/Align_fields_(Delphi)

@StephenM: You write "It ingests a data structure that identifies a report". Please be aware that there are strict limitations about what data types you can safely pass between the exe <--> dll boundary. Can you describe what this data structure looks like?

Hello all, I saw how FreeAndNil is implemented in the RTL using a "CONST [ref]" parameter and then a little "tweak" is used to NIL the variable being referenced. I wondered why the heck the object wasn't simply passed as a VAR parameter in the first place. Until I tried that out and found that it wouldn't compile. Delphi insists that you either pass the exact object type or use a typecast. What I don't understand is the reason why Delphi is so strict here; if a class derives from tObject, it still has all the original stuff in place from its ancestor so you can't really "break" anything by treating it as a tObject, so why is Delphi so strict? It feels counter-intuitive. Type tBase=Class(tObject) procedure test; end; Procedure tBase.Test; begin // end; Procedure MyFreeAndNil(VAR obj: tObject); begin obj.free; obj:=Nil; end; procedure test; var t:tbase; begin t:=tbase.create; MyFreeAndNil(t); end;

Exactly.