🚀 go-pugleaf

Why not move your initialization code to the GetService procedure?

It will like this:

function GetServices: TServices;
begin
   if _Services = nil then begin
     // Set up services: stored in global var in implementation section
   end;
   Result := _Services;
end;

It will have the advantage of not run the initialization unless it is 
necessary.

If you use threads in your code you could write like this:

var Mutex: TCriticalSection;

function GetServices: TServices;
begin
   if _Services = nil then begin
     Mutex.Enter;
     try
       if _Services = nil then begin
         // Set up services: stored in global var in ...
       end;
     finally
       Mutex.Leave;
     end;
   end;
   Result := _Services;
end;

initialization
   Mutex := TCriticalSection.Create;
finalization
   FreeAndNil(Mutex);


Gerrit Beuze wrote:
> Hi all,
> 
> I have been using dcc32 for years to build final builds.
> But currently I'm running into an odd problem:
> 
> When I build an executable (.dpr) with Delphi 7's dcc32.exe the resulting
> executable has a different unit initialization / finalization order
> than the same project build from within the IDE.
> 
> In fact: the version as build with dcc32 crashes because
> the initialization section for a unit B that "uses" unit A is called
> BEFORE the unit A initialization section. unit A obviously
> does not "use" unit B, neither any other units that indirectly use unit B.
> 
> I noticed this in several places:
> One begin very odd where unit A defines an ancestor class and unit B contains a descendant
> Even here unit B is initialized BEFORE unit A.
> 
> In this case too: built with IDE initialization order is as expected, builr with dcc32 gives bad order.
> 
> 
> And of course: the same problems occur in the finalization calling order.
> 
> 
> The basic units layout is like this:
> 
> unit A;
> 
> interface
> 
> uses Classes etc;
> 
> type
>   TServices = class (blablabla);
> 
> function GetServices: TServices;
> 
> implementation
> 
> function GetServices: TServices;
> begin
>   Result := _Services;
> end;
> 
> var
>   _Services: TServices;
> initialization
>   // Set up services: stored in global var in implementation section
> end.
> 
> ===================
> 
> unit B;
> interface
> uses unit A;
> implementation
> initialization
>   GetServices.Something; // CRASH!!
> end.
> 
> 
> I made sure all compiler settings (D-, C- etc. are defined
> identical in the project's config file that's used to build with dcc32.
> All relevant units are in the same directory, so it's not a search path problem.
> 
> 
> 
> Questions:
> 
> #1 : Any idea what's causing this?
> 
> #2: Any workaround - = how to force module initialization orders ?
> 
> And no: I cannot provide a small reproducable case.
> 
> Thanks in advance,
> 
> Gerrit Beuze
> ModelMaker Tools
> 
>