Thread overview
ERROR: circular initialization dependency
Oct 29, 2005
kris
Oct 29, 2005
Dwight Freeney
Oct 29, 2005
kris
Oct 29, 2005
Thomas Kuehne
Oct 29, 2005
Derek Parnell
Oct 30, 2005
kris
Nov 01, 2005
Kris
Nov 14, 2005
Kris
Nov 14, 2005
Derek Parnell
Nov 14, 2005
Kris
October 29, 2005
Noooooo! The return of the Son of Circular Init!

Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.

Was there a compiler change in this general area recently?
October 29, 2005
Yeah Ive seen a few problems like this while getting into larger project sizes. There is definately something flakey about the imports system. Usually I cant even tie down the problem because its something strange like order of files or imports etc. I was thinking tho, the front end code is released - Im wondering if there are maybe some unit tests we can slap onto it and drive through some of these issues to help Walter out.

kris wrote:
> Noooooo! The return of the Son of Circular Init!
> 
> Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
> 
> Was there a compiler change in this general area recently?
October 29, 2005
Indeed. I understand the import-order was fixed in v114 (with respect to 'proxy' imports), but now there appears to be a dependency on compilation order) ~ the compilation below has apparently been resolved by changing the order of files presented to the compiler. Not good.

Any ideas, Walter? I can't reproduce this myself, but there's a thread about this on the Mango forum at dsource.org describing the scenario.


Dwight Freeney wrote:
> Yeah Ive seen a few problems like this while getting into larger project sizes. There is definately something flakey about the imports system. Usually I cant even tie down the problem because its something strange like order of files or imports etc. I was thinking tho, the front end code is released - Im wondering if there are maybe some unit tests we can slap onto it and drive through some of these issues to help Walter out.
> 
> kris wrote:
> 
>> Noooooo! The return of the Son of Circular Init!
>>
>> Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
>>
>> Was there a compiler change in this general area recently?
October 29, 2005
Dwight Freeney schrieb am 2005-10-29:
> Yeah Ive seen a few problems like this while getting into larger project sizes. There is definately something flakey about the imports system. Usually I cant even tie down the problem because its something strange like order of files or imports etc. I was thinking tho, the front end code is released - Im wondering if there are maybe some unit tests we can slap onto it and drive through some of these issues to help Walter out.

The problem usually is cutting of the source to get reasonable sized test cases.

Thomas


October 29, 2005
On Sat, 29 Oct 2005 10:29:06 -0700, kris wrote:

> Noooooo! The return of the Son of Circular Init!
> 
> Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
> 
> Was there a compiler change in this general area recently?

I think that Build's order of compilation and linkage is determined by the DMD associative array hashing algorithm. Thus if different machines have different paths to the files being compile and linked, it would alter the order that the linker gets them.

But why would the linkage and/or compilation sequence be a factor? Should it really matter?

-- 
Derek Parnell
Melbourne, Australia
30/10/2005 9:08:54 AM
October 30, 2005
I can't imagine why the compilation/linkage order should matter, assuming all else is kosher. But at this time it apparently does; being the suspected causitive agent of this topic.

Perhaps Walter can shine some wisdom upon this one? Is it a bug, or a feature?



Derek Parnell wrote:
> On Sat, 29 Oct 2005 10:29:06 -0700, kris wrote:
> 
> 
>>Noooooo! The return of the Son of Circular Init!
>>
>>Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
>>
>>Was there a compiler change in this general area recently?
> 
> 
> I think that Build's order of compilation and linkage is determined by the
> DMD associative array hashing algorithm. Thus if different machines have
> different paths to the files being compile and linked, it would alter the
> order that the linker gets them.
> 
> But why would the linkage and/or compilation sequence be a factor? Should
> it really matter?
> 
November 01, 2005
It's been confirmed that the order of files, as presented to the compiler, is the only known distinction between the example program running successfully or failing with the above message.

What is one supposed to do?


"kris" <fu@bar.org> wrote in message news:dk0aud$1qrd$1@digitaldaemon.com...
> Noooooo! The return of the Son of Circular Init!
>
> Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
>
> Was there a compiler change in this general area recently?


November 14, 2005
Any word on this error?


"Kris" <fu@bar.com> wrote in message news:dk8sej$154r$1@digitaldaemon.com...
> It's been confirmed that the order of files, as presented to the compiler, is the only known distinction between the example program running successfully or failing with the above message.
>
> What is one supposed to do?
>
>
> "kris" <fu@bar.org> wrote in message news:dk0aud$1qrd$1@digitaldaemon.com...
>> Noooooo! The return of the Son of Circular Init!
>>
>> Yesterday a situation was uncovered whereby the same code would either run or fail (with the above error), when compiled on two different machines. The only distinction noted so far is the order in which files are fed to the compiler (via Build). Both machines have DMD v137.
>>
>> Was there a compiler change in this general area recently?
>
> 


November 14, 2005
On Sun, 13 Nov 2005 16:20:49 -0800, Kris wrote:

> Any word on this error?
> 
> "Kris" <fu@bar.com> wrote in message news:dk8sej$154r$1@digitaldaemon.com...
>> It's been confirmed that the order of files, as presented to the compiler, is the only known distinction between the example program running successfully or failing with the above message.
>>
>> What is one supposed to do?

Not really an answer, but I've changed Build's behaviour to be more predictable. It will now compile/link files in the order that it scans them, which is the order that the import and pragma statements are written in. So if you absolutely must have them compile in a specific order you can control that though a Build Response File.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
14/11/2005 12:24:02 PM
November 14, 2005
Hey, thanks Derek. That will certainly be useful.


"Derek Parnell" <derek@psych.ward> wrote in message news:dek8n4vlhcax$.kmfjzhm5hs38$.dlg@40tude.net...
> On Sun, 13 Nov 2005 16:20:49 -0800, Kris wrote:
>
>> Any word on this error?
>>
>> "Kris" <fu@bar.com> wrote in message news:dk8sej$154r$1@digitaldaemon.com...
>>> It's been confirmed that the order of files, as presented to the
>>> compiler,
>>> is the only known distinction between the example program running
>>> successfully or failing with the above message.
>>>
>>> What is one supposed to do?
>
> Not really an answer, but I've changed Build's behaviour to be more
> predictable. It will now compile/link files in the order that it scans
> them, which is the order that the import and pragma statements are written
> in. So if you absolutely must have them compile in a specific order you
> can
> control that though a Build Response File.
>
>
> -- 
> Derek
> (skype: derek.j.parnell)
> Melbourne, Australia
> 14/11/2005 12:24:02 PM