Crystal: [BUG] Regression: undefined reference to `dladdr'

[straight-shoota]

Builds for several shards are failing with current nightly build (Crystal 0.27.1-dev [530b91345] (2019-01-09)). Looks like a codegen bug.

• https://circleci.com/gh/crystal-lang/shards/142
• https://circleci.com/gh/straight-shoota/crinja/250
• https://circleci.com/gh/straight-shoota/sass.cr/155

The error message with shards and crinja goes like this:

/usr/bin/crystal spec
_main.o: In function `*Exception+@Exception#inspect_with_backtrace<IO::FileDescriptor>:IO::FileDescriptor':
main_module:(.text+0x7a8e): undefined reference to `dladdr'
_main.o: In function `*CallStack::decode_frame<Pointer(Void), Pointer(Void)>:(Tuple(Int64, Pointer(UInt8)) | Nil)':
main_module:(.text+0x16c53): undefined reference to `dladdr'
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/root/.cache/crystal/usr-share-crystal-src-ecr-process.cr/macro_run'  -rdynamic  -lpcre -lgc -lpthread /usr/share/crystal/src/ext/libcrystal.a -levent -lrt -L/usr/lib -L/usr/local/lib`

sass.cr has a different error, but it's most likely related, given that it pops up in the same nightly release:

crystal spec
/usr/bin/ld: C-allS-tack.o: undefined reference to symbol 'dladdr@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/root/.cache/crystal/crystal-run-spec.tmp'  -rdynamic  -lsass -lpcre -lm -lgc -lpthread /usr/share/crystal/src/ext/libcrystal.a -levent -lrt -L/usr/lib -L/usr/local/lib`
Exited with code 1

The only PR merged since yesterday's nightly build is #7282

/cc @RX14

[RX14]

Nah, it doesn't seem to be picking up the @[Link("dl")]. dladdr exists, just there's no -ldl on the linker commandline. I'm not sure why... Since the travis builds for crystal itself passed, and it built on my laptop.

[ysbaddaden]

I built crystal from master and could build and test shards locally (ubuntu 14.04). Sounds like the nightly built compiler is faulty —compiled on arch-linux-musl but running on arch-linux-gnu is maybe a hint?

[danielwestendorf]

I'm seeing this too with my nightly cron builds on travis https://travis-ci.org/danielwestendorf/message_verifier.cr/builds

[bcardiff]

I can confirm that the issue occurs after merging #7282.

Before PR:

root@627bdde4e0eb:/src# crystal --version
Crystal 0.27.1-dev [03290575b] (2019-01-16)

LLVM: 4.0.0
Default target: x86_64-unknown-linux-gnu
root@627bdde4e0eb:/src# make clean crystal
Using /usr/bin/llvm-config-4.0 [version=4.0.0]
rm -rf .build
rm -rf ./docs
rm -rf src/llvm/ext/llvm_ext.o
rm -rf src/ext/sigfault.o src/ext/libcrystal.a
g++ -c  -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc -I/usr/lib/llvm-4.0/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
cc -fPIC    -c -o src/ext/sigfault.o src/ext/sigfault.c
ar -rcs src/ext/libcrystal.a src/ext/sigfault.o
CRYSTAL_CONFIG_PATH="/src/src" CRYSTAL_CONFIG_BUILD_COMMIT="076d087" ./bin/crystal build  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib

After PR

root@627bdde4e0eb:/src# crystal --version
Crystal 0.27.1-dev [530b91345] (2019-01-16)

LLVM: 4.0.0
Default target: x86_64-unknown-linux-gnu
root@627bdde4e0eb:/src# make clean crystal
Using /usr/bin/llvm-config-4.0 [version=4.0.0]
rm -rf .build
rm -rf ./docs
rm -rf src/llvm/ext/llvm_ext.o
rm -rf src/ext/sigfault.o src/ext/libcrystal.a
g++ -c  -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc -I/usr/lib/llvm-4.0/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
cc -fPIC    -c -o src/ext/sigfault.o src/ext/sigfault.c
ar -rcs src/ext/libcrystal.a src/ext/sigfault.o
CRYSTAL_CONFIG_PATH="/src/src" CRYSTAL_CONFIG_BUILD_COMMIT="076d087" ./bin/crystal build  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
_main.o: In function `*Exception+@Exception#inspect_with_backtrace<IO::FileDescriptor>:IO::FileDescriptor':
main_module:(.text+0x7a8e): undefined reference to `dladdr'
_main.o: In function `*CallStack::decode_frame<Pointer(Void), Pointer(Void)>:(Tuple(Int64, Pointer(UInt8)) | Nil)':
main_module:(.text+0x16cd3): undefined reference to `dladdr'
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/root/.cache/crystal/src-src-ecr-process.cr/macro_run'  -rdynamic  -lpcre -lgc -lpthread /src/src/ext/libcrystal.a -levent -lrt -L/usr/lib -L/usr/local/lib`
Makefile:122: recipe for target '.build/crystal' failed
make: *** [.build/crystal] Error 1

After the nightly build the generated compiler is not checked. That is done in test-ecosystem which is not automated to run.

Besides a need for a fix on this, maybe the nightly builds should run a checkout and build the compiler as a smoke test. That would have catch this without the need of external projects.

@RX14 Maybe the context for running macros has changed after the PR and is missing [LD_]LIBRARY_PATH?

[bcardiff]

Oh, it's probably that the default target triple changed after the PR, and is using the -musl which does not have a @[Link("dl")] (like -gnu) even if running from in a non musl env. Will try debug better tomorrow.

[RX14]

Oh, it's probably that the default target triple changed after the PR

The default triple is the same, the only thing I can imagine is that setting the codegen_target for the compiler could be broken somehow.

[ysbaddaden]

Does it pass a tweaked triplet to LLVM, something that sounds harmless but happens to be?

[RX14]

@ysbaddaden I'm pretty sure it passes the triplet as-is. Besides, the codegen isn't the issue, it's the linker flags. If anyone can confirm whether it's using the musl or glibc lib_c that would narrow it down.

[bcardiff]

Found it :-)

LLVM.default_target_triple # => "x86_64-alpine-linux-musl"
Crystal::Config.default_target_triple # => "x86_64-unknown-linux-gnu"

The default triple was changed from Crystal::Config.default_target_triple to LLVM.default_target_triple in the PR. The definition of the former embeds the value of CRYSTAL_CONFIG_TARGET using during the build.