digitalmars.D.ldc - Bootstrap crash on Solaris 2.11/5.11 - uninitialized mem access
- Rick V (11/11) Jan 01 2019 So, I decided to get into D at the behest of a few of my colleagues.
- Rick V (14/14) Jan 01 2019 Forgot to mention that the new LDC is either of HEAD or the 1.13.0
- kinke (4/9) Jan 01 2019 Sounds familiar; this is probably due to a buggy linker (see 1.13
- Rick V (7/11) Jan 01 2019 Not an option; LLD is installed, but the LDC 0.17 bootstrap unconditiona...
- David Nadlinger (4/13) Jan 02 2019 So just to clarify, is this the v1.13 binary crashing as built by v0.17,...
- Rick V (12/20) Jan 02 2019 It would be the newly-compiled v1.13, as built by 0.17.
- Rick V (18/26) Jan 02 2019 edit:....and these C++ compilers are hardcoded to call the native Oracle...
- kinke (7/11) Jan 03 2019 I have no idea about and no interest in Solaris and its linker
- kinke (8/15) Jan 03 2019 Just for completeness: with v1.12 as host compiler for
- David Nadlinger (9/12) Jan 03 2019 Rick is using a compiler (doesn't matter that it's 1.13) compiled by
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)[]).
Jan 01 2019
"Rick V" <rick snowlight.net>
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)[]).
Jan 01 2019
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).
Jan 01 2019
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).
Jan 01 2019
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:So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — DavidThe *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).
Jan 02 2019
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:So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — DavidThe *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).
Jan 02 2019
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:So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — DavidThe *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).
Jan 02 2019
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.
Jan 03 2019
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.
Jan 03 2019
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
Jan 03 2019
On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger wrote: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.Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 03 2019
Now that I got my hands on the current release of Oracle DevStudio (5.15/12.6), I'm going to build a GNU CC configured to use GAS and GLD (all the GNU tools are prefixed here) I mean, language support is *there*, it's the underlying plumbing that's driving me nuts (and hoping that NetBSD support is advancing soon!) Cheers Rick On Thursday, 3 January 2019 at 22:25:12 UTC, kinke wrote:On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger wrote: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.Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 06 2019
update: replaced system GLD without plugin support, etc with custom GLD build works fine now Cheers Rick "Rick V" wrote in message news:xkjellyzzpgfidpzralc forum.dlang.org... Now that I got my hands on the current release of Oracle DevStudio (5.15/12.6), I'm going to build a GNU CC configured to use GAS and GLD (all the GNU tools are prefixed here) I mean, language support is *there*, it's the underlying plumbing that's driving me nuts (and hoping that NetBSD support is advancing soon!) Cheers Rick On Thursday, 3 January 2019 at 22:25:12 UTC, kinke wrote:On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger wrote: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.Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 08 2019