www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - dmd v2.065 compatibility

reply "Chris" <wendlec tcd.ie> writes:
[1]
Yesterday I tried to build a project with dub. dub had downloaded 
and installed dmd v2.065. The project and accompanying library 
had been built with dmd v2.064. dub said that the project was up 
to date and didn't need compiling. However, I got a long long 
error message informing me that there were undefined references 
(see below). I recompiled the library with dmd v2.065 and 
everything worked fine. Yet I wonder, is this behavior normal, 
i.e. dub says its alright but not really?

[2]
Another issue I encountered was when I recompiled the library, 
dmd 2.065 gave me an error that a goto statement skipped a 
variable. The case is as follows:

if (condition) {
   goto Label;
}

auto variable = getVariableValue(); // Only needed, if 
"condition" above not true
// do things with variable here (needed for what comes after 
"Label"

Label:
// Finish everything

I know that scope would be better and this is the only goto I 
have left. In order for the code to compile I had to move (as a 
quick fix)

auto variable = getVariableValue();

to before the if (condition) statement. Is this by design? If 
yes, why? Enlighten me, cos it shouldn't really matter, should it?

[3]
Last but not least, could [2] have triggered the error I got in 
[1]?

[Part of error message]
source/lib//libdlts.a(regex_770_e66.o): In function 
`_D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa':
/usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4find
FNaNfAxaZAxa+0x53): 
undefined reference to `_D3std5ascii6_ctypeyG128h'
/usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findM
NaNfAxaZAxa+0x113): 
undefined reference to `_D3std5ascii6_ctypeyG128h'
Mar 14 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 [2]
 Another issue I encountered was when I recompiled the library, 
 dmd 2.065 gave me an error that a goto statement skipped a 
 variable. The case is as follows:

 if (condition) {
   goto Label;
 }

 auto variable = getVariableValue(); // Only needed, if 
 "condition" above not true
 // do things with variable here (needed for what comes after 
 "Label"

 Label:
 // Finish everything

 I know that scope would be better and this is the only goto I 
 have left. In order for the code to compile I had to move (as a 
 quick fix)

 auto variable = getVariableValue();

 to before the if (condition) statement. Is this by design?


D specs state that gotos can't be used to skip a variable 
definition. In the last compiler version this rule has being 
implemented and enforced. So the original code was not 
D-conformant.

Bye,
bearophile
Mar 14 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 14 March 2014 at 10:49:57 UTC, bearophile wrote:

 Chris:


 [2]
 Another issue I encountered was when I recompiled the library, 
 dmd 2.065 gave me an error that a goto statement skipped a 
 variable. The case is as follows:

 if (condition) {
  goto Label;
 }

 auto variable = getVariableValue(); // Only needed, if 
 "condition" above not true
 // do things with variable here (needed for what comes after 
 "Label"

 Label:
 // Finish everything

 I know that scope would be better and this is the only goto I 
 have left. In order for the code to compile I had to move (as 
 a quick fix)

 auto variable = getVariableValue();

 to before the if (condition) statement. Is this by design?


 D specs state that gotos can't be used to skip a variable 
 definition. In the last compiler version this rule has being 
 implemented and enforced. So the original code was not 
 D-conformant.

 Bye,
 bearophile


Thanks for the answer. Any particular reason why the variable 
declaration should not be skipped? Security? Code generation?
Mar 14 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 Thanks for the answer. Any particular reason why the variable 
 declaration should not be skipped? Security? Code generation?


In D all variables get initialized at the definition point 
(unless you add a "= void"). A goto skips this initialization, 
and this breaks certain safety generates D relies on.

Bye,
bearophile
Mar 14 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 In D all variables get initialized at the definition point 
 (unless you add a "= void"). A goto skips this initialization, 
 and this breaks certain safety generates D relies on.


Look for  safe functions:

void main()  safe {
     int* p = void;
}


test.d(2,10): Error: variable test.main.p void initializers for 
pointers not allowed in safe functions

Bye,
bearophile
Mar 14 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 14 March 2014 at 11:14:15 UTC, bearophile wrote:

 Chris:


 Thanks for the answer. Any particular reason why the variable 
 declaration should not be skipped? Security? Code generation?


 In D all variables get initialized at the definition point 
 (unless you add a "= void"). A goto skips this initialization, 
 and this breaks certain safety generates D relies on.

 Bye,
 bearophile


Interesting, though, that I got away with it until v2.065.
Mar 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 14 March 2014 at 11:41:49 UTC, Chris wrote:

 Interesting, though, that I got away with it until v2.065.


DMD still has quite a lot of "accepts-invalid" bugs.
Mar 14 2014
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 3/14/2014 7:43 PM, Chris wrote:

 [1]
 Yesterday I tried to build a project with dub. dub had downloaded and
 installed dmd v2.065. The project and accompanying library had been


I'm curious what you mean by this. I don't see any way to get DMD 
through dub.


 built with dmd v2.064. dub said that the project was up to date and
 didn't need compiling. However, I got a long long error message
 informing me that there were undefined references (see below). I
 recompiled the library with dmd v2.065 and everything worked fine. Yet I
 wonder, is this behavior normal, i.e. dub says its alright but not really?


This is normal. dub doesn't have any idea which version of which 
compiler a set of binary files was built with. What it does is to 
compare the times of the binaries with those of the source modules to 
determine if anything has changed. If not, it doesn't build. This is 
essentially how most build tools behave, no matter which language you're 
working with.

Of course, it would be possible to implement the tracking of compiler 
versions. The only way I can see to do that off the top of my head is 
that dub would have to maintain a registry that logs the compiler 
version used on the last compile for each binary, then parse the output 
of 'dmd' or 'dmd --help' to find the version number (and do that for 
each supported compiler) of the compiler currently in use. But it would 
have to do that at the beginning of every compile. In my mind, the cost 
greatly outweighs the benefit.

Just 'dub build --force' when you upgrade your compiler.
Mar 14 2014
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 14 March 2014 at 14:11:45 UTC, Mike Parker wrote:

 On 3/14/2014 7:43 PM, Chris wrote:

 [1]
 Yesterday I tried to build a project with dub. dub had 
 downloaded and
 installed dmd v2.065. The project and accompanying library had 
 been


 I'm curious what you mean by this. I don't see any way to get 
 DMD through dub.


I wasn't exact, when I downloaded dub, I was asked to download 
dmd, I downloaded the latest version.


 built with dmd v2.064. dub said that the project was up to 
 date and
 didn't need compiling. However, I got a long long error message
 informing me that there were undefined references (see below). 
 I
 recompiled the library with dmd v2.065 and everything worked 
 fine. Yet I
 wonder, is this behavior normal, i.e. dub says its alright but 
 not really?


 This is normal. dub doesn't have any idea which version of 
 which compiler a set of binary files was built with. What it 
 does is to compare the times of the binaries with those of the 
 source modules to determine if anything has changed. If not, it 
 doesn't build. This is essentially how most build tools behave, 
 no matter which language you're working with.



 Of course, it would be possible to implement the tracking of 
 compiler versions. The only way I can see to do that off the 
 top of my head is that dub would have to maintain a registry 
 that logs the compiler version used on the last compile for 
 each binary, then parse the output of 'dmd' or 'dmd --help' to 
 find the version number (and do that for each supported 
 compiler) of the compiler currently in use. But it would have 
 to do that at the beginning of every compile. In my mind, the 
 cost greatly outweighs the benefit.

 Just 'dub build --force' when you upgrade your compiler.
Mar 14 2014
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 3/14/2014 7:43 PM, Chris wrote:


 [3]
 Last but not least, could [2] have triggered the error I got in [1]?

 [Part of error message]
 source/lib//libdlts.a(regex_770_e66.o): In function
 `_D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa':

 /usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x53):
 undefined reference to `_D3std5ascii6_ctypeyG128h'
 /usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x113):
 undefined reference to `_D3std5ascii6_ctypeyG128h'


Apparently, dub determined that even though no compilation needed to 
take place, linking was needed and it ran the link step. These errors 
are most likely because of the version mismatch between the project's 
object files (built against 2.064 Phobos) and the 2.065 Phobos archive.
Mar 14 2014
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 14.03.2014 11:43, schrieb Chris:

 [1]
 Yesterday I tried to build a project with dub. dub had downloaded and
 installed dmd v2.065. The project and accompanying library had been
 built with dmd v2.064. dub said that the project was up to date and
 didn't need compiling. However, I got a long long error message
 informing me that there were undefined references (see below). I
 recompiled the library with dmd v2.065 and everything worked fine. Yet I
 wonder, is this behavior normal, i.e. dub says its alright but not really?


DUB currently doesn't take the compiler version into account when 
generating the hash value used to cache the intermediate build results 
(in .dub/build/*), which is the reason it thought everything was up to 
date. This will get fixed for the next version.
Mar 20 2014