On Friday, 31 July 2015 at 15:58:24 UTC, Gerald Jansen wrote:
> I'm not sure if this is the right place to report issues. I downloaded dmd.2.068.0-b2.linux.zip, unzipped it and added the bin64 directory to my path. The standard hello.d compiles fine but segfaults immediately. Details follow. Also rdmd segfaults with the same message. (The same process with the 2.067.1 zip works fine on the same box.)
>
> Details:
> gjansen@gamma:~$ uname -a
> Linux gamma 2.6.32-279.14.1.el6.x86_64 #1 SMP Mon Oct 15 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
> gjansen@gamma:~$ dmd --version
> DMD64 D Compiler v2.068.0-b2
> Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
> gjansen@gamma:~$ dmd hello.d
> gjansen@gamma:~$ ./hello
> Segmentation fault (core dumped)
> gjansen@gamma:~$ gdb hello
> <snip>
> (gdb) run
> Starting program: /ricerca/gjansen/hello
> [Thread debugging using libthread_db enabled]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004418e1 in _d_initMonoTime ()
> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6_3.6.x86_64

Hi Gerald,

MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality.

Unfortunately, it looks like MonoTime does not currently support your kernel version. It needs at least Linux 2.6.39. The reason being is that it has the CLOCK_BOOTTIME clock which was implemented in Linux 2.6.39. Without this clock, the minimum version would be Linux 2.6.32.

If I had to hazard a guess, I'd say the offending segfault is coming from calling clock_getres(clockArg, &ts) (where clockArg is essentially CLOCK_BOOTTIME) in _d_initMonoTime(). It seems to call this for all supported Clocks for your platform.

Hopefully some code can be added to only allow CLOCK_BOOTTIME on kernels that support it. 2.6.32 is still supported as a longterm kernel release.

Regards,
Kelet

On Friday, 31 July 2015 at 17:56:23 UTC, Kelet wrote:
> On Friday, 31 July 2015 at 15:58:24 UTC, Gerald Jansen wrote:
>> [...]
>
> Hi Gerald,
>
> MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality.
>
> [...]

To expand on this, while MonoTime was in 2.067.1, it was not initialized in rt_init at the time.

Regards,
Kelet

On 31.07.2015 02:41, Joseph Cassman wrote:
> Not sure if it ties in with DMD or not but a libucrt.lib missing error
> was one of the several errors I got when trying to use VS2015 with DMD +
> Win64. I do not get the error with VS2013u5 (the file exists with both
> installations but is only recognized for the later for some reason).
> Posting in case it helps isolate the issue for VisualD as well.
>
> Joseph

I just updated my VS2015 installation and can confirm the error message regarding libucrt.lib.

I found the library in the folder "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64". You can add it to the library search paths in "Tools->Options->Projects and Solutions->Visual D->DMD Directories->x64".

Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos.

On 31.07.2015 09:54, Kagamin wrote:
> On Thursday, 30 July 2015 at 18:54:03 UTC, Rainer Schuetze wrote:
>> That was fast. Thanks!
>
> README in github repo still has some outdated links to dsource. Also
> bugzilla address is https://issues.dlang.org/

I removed most dsource links (also from the documentation), but some are still valid and not available elsewhere (e.g. download links of files only found there).

I didn't immediately get what you meant with the bugzilla address because it worked due to redirection. I'll update that later...

On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
> https://www.microsoft.com/en-us/download/details.aspx?id=46886

Does it include the C++ compiler and linker?

On Friday, 31 July 2015 at 17:56:23 UTC, Kelet wrote:
> Hi Gerald,
>
> MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality.

Thanks, filed as https://issues.dlang.org/show_bug.cgi?id=14863.

On 02.08.2015 11:38, Martin Nowak wrote:
> On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
>> https://www.microsoft.com/en-us/download/details.aspx?id=46886
>
> Does it include the C++ compiler and linker?

No, the VS shell does not include any specific language support and libraries.

On Sunday, 2 August 2015 at 09:38:23 UTC, Martin Nowak wrote:
> On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
>> https://www.microsoft.com/en-us/download/details.aspx?id=46886
>
> Does it include the C++ compiler and linker?

I think it contains a linker, but I'm not 100% sure. See https://msdn.microsoft.com/en-us/library/bb129445.aspx for some info

On Sunday, 2 August 2015 at 09:20:44 UTC, Rainer Schuetze wrote:
>
>
> On 31.07.2015 02:41, Joseph Cassman wrote:
>> [...]
>
> I just updated my VS2015 installation and can confirm the error message regarding libucrt.lib.
>
> I found the library in the folder "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64". You can add it to the library search paths in "Tools->Options->Projects and Solutions->Visual D->DMD Directories->x64".
>
> Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos.

Very cool. That change to the C runtime also explains some of the errors I was getting. Thanks for the explanation.

Joseph

On 08/02/2015 11:20 AM, Rainer Schuetze wrote:
> Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos.

You think we can work that out soon enough? https://issues.dlang.org/show_bug.cgi?id=14849#c7

It seems that we need to link to a certain flavor of the runtime.