ldc build issue seems to persist
maxhaton opened this issue · 17 comments
Command:
make
Log:
ldmd2 -c -of"obj/driver/sdfmt.o" "src/driver/sdfmt.d" -makedeps="obj/driver/sdfmt.o.deps" -m64 -Isrc -w -debug -g -Iimport
ldmd2 -c -ofobj/format.o -makedeps="obj/format.o.deps" src/format/writer.d src/format/span.d src/format/rulevalues.d src/format/chunk.d src/format/config.d src/format/parser.d -m64 -Isrc -w -debug -g
ar rcs lib/libsdfmt.a obj/format.o
ldmd2 -c -ofobj/libconfig.o src/config/jsonparser.d src/config/value.d src/config/build.d -makedeps="obj/libconfig.o.deps" -m64 -Isrc -w -debug -g
ar rcs lib/libconfig.a obj/libconfig.o
ldmd2 -c -of"obj/libsource.o" src/source/manager.d src/source/lexbase.d src/source/name.d src/source/jsonlexer.d src/source/exception.d src/source/location.d src/source/lexstring.d src/source/parserutil.d src/source/context.d src/source/strtoint.d src/source/dlexer.d src/source/lexnumeric.d src/source/util/lookup.d src/source/util/utf8.d -makedeps="obj/libsource.o.deps" -m64 -Isrc -w -debug -g
ar rcs lib/libsource.a obj/libsource.o
ldmd2 -of"bin/sdfmt" obj/driver/sdfmt.o lib/libsdfmt.a lib/libconfig.a lib/libsource.a -m64 -Isrc -w -debug -g -Xcc=-fuse-ld=lld -Xcc=-lstdc++ -Xcc=-export-dynamic
ldmd2 -c -of"obj/driver/sdc.o" "src/driver/sdc.d" -makedeps="obj/driver/sdc.o.deps" -m64 -Isrc -w -debug -g -Iimport
ldmd2 -c -ofobj/sdc.o -makedeps="obj/sdc.o.deps" src/sdc/config.d src/sdc/sdc.d -m64 -Isrc -w -debug -g -Iimport
ar rcs lib/libsdc.a obj/sdc.o
ldmd2 -c -of"obj/libd.o" src/d/object.d src/d/common/qualifier.d src/d/common/type.d src/d/common/node.d src/d/common/builtintype.d src/util/visitor.d src/util/bitfields.d src/util/fastcast.d src/util/terminal.d src/util/main.d src/util/testinfra.d src/d/ast/type.d src/d/ast/statement.d src/d/ast/conditional.d src/d/ast/expression.d src/d/ast/declaration.d src/d/ast/identifier.d src/d/ir/symbol.d src/d/ir/instruction.d src/d/ir/type.d src/d/ir/expression.d src/d/ir/dscope.d src/d/ir/error.d src/d/parser/ambiguous.d src/d/parser/dtemplate.d src/d/parser/type.d src/d/parser/statement.d src/d/parser/adt.d src/d/parser/conditional.d src/d/parser/expression.d src/d/parser/base.d src/d/parser/declaration.d src/d/parser/dmodule.d src/d/parser/identifier.d src/d/semantic/sizeof.d src/d/semantic/type.d src/d/semantic/statement.d src/d/semantic/evaluator.d src/d/semantic/aliasthis.d src/d/semantic/vrp.d src/d/semantic/expression.d src/d/semantic/closure.d src/d/semantic/semantic.d src/d/semantic/defaultinitializer.d src/d/semantic/symbol.d src/d/semantic/flow.d src/d/semantic/scheduler.d src/d/semantic/typepromotion.d src/d/semantic/dtemplate.d src/d/semantic/datalayout.d src/d/semantic/caster.d src/d/semantic/declaration.d src/d/semantic/dmodule.d src/d/semantic/mangler.d src/d/semantic/identifier.d -makedeps="obj/libd.o.deps" -m64 -Isrc -w -debug -g
ar rcs lib/libd.a obj/libd.o
ldmd2 -c -ofobj/libd-llvm.o src/d/llvm/global.d src/d/llvm/type.d src/d/llvm/statement.d src/d/llvm/intrinsic.d src/d/llvm/evaluator.d src/d/llvm/local.d src/d/llvm/expression.d src/d/llvm/datalayout.d src/d/llvm/backend.d src/d/llvm/codegen.d src/d/llvm/constant.d import/llvm/c/target.d -makedeps="obj/libd-llvm.o.deps" -m64 -Isrc -w -debug -g -Iimport
ar rcs lib/libd-llvm.a obj/libd-llvm.o
ldmd2 -c -ofobj/sdmd.o -makedeps="obj/sdmd.o.deps" sdlib/d/rt/eh.d sdlib/d/rt/object.d sdlib/d/rt/dwarf.d -m64 -Isdlib
sdlib/d/rt/object.d(32): Error: undefined identifier `_xopEquals` in module `object`
#0 0x00000000036e1803 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/mhh/dlang/ldc-1.27.1/bin/ldc2+0x36e1803)
Error: Error executing /home/mhh/dlang/ldc-1.27.1/bin/ldc2: Segmentation fault (core dumped)
make: *** [sdlib/sdmd.mak:13: obj/sdmd.o] Error 1
What's the actual problem here? It looks like this is a bug in LDC. Can we loop someone from LDC in? @kinke maybe?
It's possible that it's something weird going in the ldc glue but recall that we have the hack in place to tell dmd where to actually look
NATIVE_DMD_FLAGS = $(shell echo "" | dmd -v - 2> /dev/null | sed -ne 's/^DFLAGS\s*//p')
NATIVE_DMD_IMPORTS ?= $(filter -I%, $(NATIVE_DMD_FLAGS))
LIBSDMD_IMPORTS = $(NATIVE_DMD_IMPORTS) -Isdlib
This looks like a follow-up error after the 'Error: undefined identifier _xopEquals in module object'. LDC's glue layer might not be very resilient when it comes to projects with custom object.d missing misc. hooks.
This looks like a follow-up error after the 'Error: undefined identifier
_xopEqualsin moduleobject'. LDC's glue layer might not be very resilient when it comes to projects with customobject.dmissing misc. hooks.
It's.not a custom object.d as per se
What's https://github.com/snazzy-d/sdc/blob/master/sdlib/object.d then? It applies to all other modules compiled in the same cmdline at least. E.g., the empty TypeInfo class surely trips up LDC at some point; if the point is to prevent TypeInfos from being emitted, there should be no TypeInfo class at all (that was one point of making druntime 'pay-as-you-go').
I think this is a bug in LDC. This file is not being compiled by LDC and is not supposed to be used by LDC. Is it because the include path and take precedence over the builtin druntime?
What's https://github.com/snazzy-d/sdc/blob/master/sdlib/object.d then?
It is the object.d to be used by sdc, ldc do not need to use that.
Is it because the include path and take precedence over the builtin druntime?
Likely, the builtin one has lowest priority. Using -v shows the imported files (just like DMD).
Using an LDC with enabled assertions might be helpful to diagnose missing/incompatible object.d stuff; can be downloaded from https://github.com/ldc-developers/ldc/releases/tag/CI.
[With LDC v1.30.0-beta1, I don't get a segfault anymore, just the missing object._xopEquals error.]
$ ldmd2 -c -ofobj/sdmd.o -makedeps="obj/sdmd.o.deps" sdlib/d/rt/eh.d sdlib/d/rt/object.d sdlib/d/rt/dwarf.d -m64 -Isdlib -v
binary /home/mkinkelin/dlang/ldc-1.30.0-beta1-sym2/bin/ldc2
[…]
import object (sdlib/object.d)
[…]
Ok, so the wrong object.d is being used here. Is there a way to get ldc to vomit what the default objet.d (or alternatively druntime's path) so that it can be passed explicitly to the build command?
Not really, it's set in etc/ldc2.conf (usually ../import relative to LDC bin dir). But the same problem should apply to DMD and GDC, so a general solution is needed (i.e., making sure that sdlib/object.d isn't importable). Wrt. object._xopEquals being referenced eagerly for LDC, that's just caused by a different TypeInfo emission strategy (compared to DMD).
A generic solution would indeed be beneficial, but a solution, even if not generic, would be better than none.
I don't think LDC is necessarily wrong to reference parts of object.d eagerly. I have no expectation that LDC would work with SDC's version of object.d (for instance, class typeinfo are purposefully not ABI compatible so they can downcast very efficiently).
It work for DMD by extracting the default DFLAGS using:
$ echo "" | dmd -v - 2> /dev/null | sed -ne 's/^DFLAGS\s*//p'
Unfortunately, this doesn't work for LDC.
This yields the dir containing host compiler's object.d with both LDC and DMD (so the host druntime root in both cases):
$ echo "int x;" | $DC -v -o- - 2>/dev/null | sed -ne 's/^import object\s*(\(.*\))$/\1/p' | xargs dirnameSo adding that as -I import path before -Isdlib should prevent the SDC object.d import.
It tirns out there is still a problem, but this one specifically is solved, so I'm closing this.