So, I decided to get into D at the behest of a few of my colleagues.

Sure. Why not? Tried bootstrapping on a netbsd system, only got as far as building a freestanding Symantec/DMD 2.067.1 because NetBSD/OpenBSD support in druntime is still in progress.

Switched to my Solaris box, bootstrapped LDC 0.17, druntime-ldc and phobos-ldc 2.068 for both 32-bit and 64-bit variants. (Both are native 64-bit compilers, as the included LLVM 4.0 is.)

The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).

Forgot to mention that the new LDC is either of HEAD or the 1.13.0 release--neither one works.

"Rick V"  wrote in message news:q0fgef$hij$1@digitalmars.com...

So, I decided to get into D at the behest of a few of my colleagues.

Sure. Why not? Tried bootstrapping on a netbsd system, only got as far as
building a freestanding Symantec/DMD 2.067.1 because NetBSD/OpenBSD support
in druntime is still in progress.

Switched to my Solaris box, bootstrapped LDC 0.17, druntime-ldc and
phobos-ldc 2.068 for both 32-bit and 64-bit variants. (Both are native
64-bit compilers, as the included LLVM 4.0 is.)

The *new* LDC crashes when compiling anything, at
registerPredefinedVersions(), while calling
VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets
random garbage at dmd.identifier.Identifier.idPool(const(char)[]). 

On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
> The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).

Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).

Not an option; LLD is installed, but the LDC 0.17 bootstrap unconditionally uses Solaris LD...gold is not an option because of invalid linker flags

"kinke"  wrote in message news:snpqurmvtvmvfzpijmcu@forum.dlang.org...

On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
> The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).

Sounds familiar; this is probably due to a buggy linker (see 1.13
release notes; LDC defaults to gold because older bfd wrongly
strips ModuleInfos). So try gold or a newer bfd (or lld). 

On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
> On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
>> The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
>
> Sounds familiar; this is probably due to a buggy linker (see 1.13
> release notes; LDC defaults to gold because older bfd wrongly
> strips ModuleInfos). So try gold or a newer bfd (or lld).

So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13?

 — David

It would be the newly-compiled v1.13, as built by 0.17.
LDC 0.17 calls either of GCC 6, 8, or Oracle DevStudio C 12u1 to perform final link edits.
0.17 can build D 2.068 apps correctly.
1.13 cannot even bootstrap its own Druntime 2.084.

-rick

"David Nadlinger"  wrote in message news:mailman.6172.1546488631.29801.digitalmars-d-ldc@puremagic.com...

On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
> On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
>> The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
>
> Sounds familiar; this is probably due to a buggy linker (see 1.13
> release notes; LDC defaults to gold because older bfd wrongly
> strips ModuleInfos). So try gold or a newer bfd (or lld).

So just to clarify, is this the v1.13 binary crashing as built by v0.17,
or a compiler built by v1.13?

 — David 

edit:....and these C++ compilers are hardcoded to call the native Oracle DevStudio link editor
even GCC recommends using the Developer Studio binutils over its own on Solaris...

-rick

"Rick V"  wrote in message news:q0k70o$rgi$1@digitalmars.com...

It would be the newly-compiled v1.13, as built by 0.17.
LDC 0.17 calls either of GCC 6, 8, or Oracle DevStudio C 12u1 to perform
final link edits.
0.17 can build D 2.068 apps correctly.
1.13 cannot even bootstrap its own Druntime 2.084.

-rick

"David Nadlinger"  wrote in message
news:mailman.6172.1546488631.29801.digitalmars-d-ldc@puremagic.com...

On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
> On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
>> The *new* LDC crashes when compiling anything, at registerPredefinedVersions(), while calling VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
>
> Sounds familiar; this is probably due to a buggy linker (see 1.13
> release notes; LDC defaults to gold because older bfd wrongly
> strips ModuleInfos). So try gold or a newer bfd (or lld).

So just to clarify, is this the v1.13 binary crashing as built by v0.17,
or a compiler built by v1.13?

 — David 

On Thursday, 3 January 2019 at 05:39:39 UTC, Rick V wrote:
> edit:....and these C++ compilers are hardcoded to call the native Oracle DevStudio link editor
> even GCC recommends using the Developer Studio binutils over its own on Solaris...

I have no idea about and no interest in Solaris and its linker situation. Anyway, there have been changes with 1.13 wrt. ModuleInfos (affecting run module ctors, which is the problem you are seeing), so you shouldn't have any issues with 1.12. Recent bfd on Linux works fine with v1.13, e.g., the one shipping with Ubuntu 18.04; ancient gold from Ubuntu 14.04 works fine too.

On Thursday, 3 January 2019 at 18:09:23 UTC, kinke wrote:
> I have no idea about and no interest in Solaris and its linker situation. Anyway, there have been changes with 1.13 wrt. ModuleInfos (affecting run module ctors, which is the problem you are seeing), so you shouldn't have any issues with 1.12. Recent bfd on Linux works fine with v1.13, e.g., the one shipping with Ubuntu 18.04; ancient gold from Ubuntu 14.04 works fine too.

Just for completeness: with v1.12 as host compiler for 1.13/master, you have

* the `-gcc` option to select the C compiler for linking (gcc/clang; might be available in 0.17 too),
* the `-linker=blub` option, which translates to `-fuse-ld=blub` in the gcc/clang command line, and
* the `-Xcc` option for arbitrary gcc/clang command line options.

On 3 Jan 2019, at 18:09, kinke via digitalmars-d-ldc wrote:
> I have no idea about and no interest in Solaris and its linker situation. Anyway, there have been changes with 1.13 wrt. ModuleInfos (affecting run module ctors, which is the problem you are seeing)

Rick is using a compiler (doesn't matter that it's 1.13) compiled by 0.17, though. Also, any regressions regarding --gc-sections shouldn't affect Solaris, as the option isn't even active there. In fact, I think Solaris even uses the old _Dmodule_ref scheme for module registration.

That being said, if the symptoms match the ModuleInfo-related issues you have been seeing, it's reasonable to suspect another issue affecting `ModuleInfo`s or static constructors on Solaris.

 —David