January 05, 2018
On Friday, 5 January 2018 at 14:30:13 UTC, Глеб Куликов/Gleb Kulikov wrote:
> Martin Nowak wrote:
>
>
>> 
>> Glad to announce D 2.078.0.
>
> Hello and Happy New Year ! :)
>
> Unfortunally, linux x86_64 version(*) has problems:
>
> (*) from red hat rpm
>

I also setup from the RH rpm and it works fine here, also in GDB.
Can you reproduce it at each run ?
January 05, 2018
user789 wrote:

>>
>> Unfortunally, linux x86_64 version(*) has problems:
> 
> I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?

Yes,
it's fully reproducable in number of x86_64 systems:

system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65

with the same behavior, so it is not installation -- dependent.


all previous versions of dmd works good.

ldc2 1.7.0-beta1 and older works ok as well.


all another functionality, except of fwrite, seems to be ok.


--

yours sincerely,...
January 05, 2018
On Friday, 5 January 2018 at 15:30:39 UTC, gleb wrote:
> user789 wrote:
>
>>>
>>> Unfortunally, linux x86_64 version(*) has problems:
>> 
>> I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?
>
> Yes,
> it's fully reproducable in number of x86_64 systems:
>
> system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65
>
> with the same behavior, so it is not installation -- dependent.
>
>
> all previous versions of dmd works good.
>
> ldc2 1.7.0-beta1 and older works ok as well.
>
>
> all another functionality, except of fwrite, seems to be ok.
>
>
> --
>
> yours sincerely,...

I've seen your report. kernel is at 4.14 and glibc is 2.26 here, although it's hard to say if this is the problem but your systems seem not to be updated since about a full year.
January 06, 2018
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger wrote:

> This is slightly inaccurate. Regular stack cleanup doesn't involve the runtime at all; druntime only comes into play for exception handling. Since destructors also need to be run when the scope is left by an exception, they are implemented via `try {} finally {}` internally. The EH part of these depends on druntime, but not the regular path.
>
>
>
> This is somewhat confusingly worded as well. It's actually mostly the other way around – druntime depends on ModuleInfo to be emitted, crucially for static constructor, destructors and unit tests to be run. At least without shared libraries in the picture, it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program.
>
>  — David

Thanks, David!


January 06, 2018
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger wrote:

> it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program.

ModuleInfo is declared and defined in druntime (https://github.com/dlang/druntime/blob/7bfaa8c0755771b807a8344b8c0bfcf73aec7c82/src/object.d#L1443).  If one is doing a druntime-less build, how would it be possible have a set of `ModuleInfo`s to manually look up?

Mike


January 08, 2018
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
> Glad to announce D 2.078.0.
>
> This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks.
>
> Thanks to everyone involved in this 👏 https://dlang.org/contributors.html.
>
> http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html
>
> - -Martin

It seems vs-auto-detection does not work with the Visual Studio 2017 Community version:

I executed "vcvars64.bat". After that environment variable PATH contains following
entries:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;
C:\Program Files (x86)\Microsoft Visual
...

dmd app.d -m64
Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH

I checked the location and link.exe is available in the very first element of PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\Hostx64\x64

Could you check?

Kind regards
André


January 08, 2018
On Monday, 8 January 2018 at 07:56:18 UTC, Andre Pany wrote:
> On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
>> Glad to announce D 2.078.0.
>>
>> This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks.
>>
>> Thanks to everyone involved in this 👏 https://dlang.org/contributors.html.
>>
>> http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html
>>
>> - -Martin
>
> It seems vs-auto-detection does not work with the Visual Studio 2017 Community version:
>
> I executed "vcvars64.bat". After that environment variable PATH contains following
> entries:
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages;
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;
> C:\Program Files (x86)\Microsoft Visual
> ...
>
> dmd app.d -m64
> Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH
>

Note the double backslash, its getting confused.

January 08, 2018

On 08.01.2018 08:56, Andre Pany wrote:
> On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
>> Glad to announce D 2.078.0.
>>
>> This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks.
>>
>> Thanks to everyone involved in this 👏 https://dlang.org/contributors.html.
>>
>> http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html
>>
>> - -Martin
> 
> It seems vs-auto-detection does not work with the Visual Studio 2017 Community version:
> 
> I executed "vcvars64.bat". After that environment variable PATH contains following
> entries:
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages;
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;
> C:\Program Files (x86)\Microsoft Visual
> ...
> 
> dmd app.d -m64
> Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH
> 
> I checked the location and link.exe is available in the very first element of PATH environment variable:
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\Hostx64\x64
> 
> Could you check?
> 
> Kind regards
> André
> 
> 

Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough

[Environment64]
LIB=%@P%\..\lib64
DFLAGS=%DFLAGS% -L/OPT:NOICF

When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017.
January 09, 2018
On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
>
> Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough
>
> [Environment64]
> LIB=%@P%\..\lib64
> DFLAGS=%DFLAGS% -L/OPT:NOICF
>
> When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017.

Thanks a lot for the information. My use case is a XMake build plugin (Python) for D which currently only supports X86 COFF. Adapting the sc.ini from Python is only working with ugly workarounds as duplicate keys in sc.ini is not really allowed. I will wait until the corresponding pull request is merged. Does it make sense to open an issue or will it be anyway available in next relase?

Kind regards
André
January 09, 2018
On 01/05/2018 03:30 PM, Глеб Куликов/Gleb Kulikov wrote:
> Martin Nowak wrote:
> 
> 
>>
>> Glad to announce D 2.078.0.
> 
> Hello and Happy New Year ! :)
> 
> Unfortunally, linux x86_64 version(*) has problems:

Please file a bug report under https://issues.dlang.org/enter_bug.cgi
and link to it from here.
This is an announce forum, and soon this information is lost.

Please make sure to list necessary information to reproduce this issue
(e.g. cc --version; ld -v; uname -a; cat /etc/redhat-release).
If it works in 2.077.1, it should be filed as regression and the bug
title should start with [2.078].

-Martin