On Monday, 11 May 2020 at 13:29:51 UTC, Denis Feklushkin wrote:
> It's good. I tried define some external(C) symbol near of _Dmodule_ref and then use it from main() - linking with this symbol works ok. So, this problem only with "hidden"  calls invoked by compiler.

_d_run_main isn't invoked by magic compiler code. - What linker are you using (linker, not gcc linker driver)? We default to gold (-linker=gold) for Linux because there have been numerous LTO issues with default bfd in the past (and the LLVM plugin is (primarily?) for gold, not bfd).

On Monday, 11 May 2020 at 15:25:24 UTC, kinke wrote:

> - What linker are you using (linker, not gcc linker driver)? We default to gold (-linker=gold) for Linux because there have been numerous LTO issues with default bfd in the past (and the LLVM plugin is (primarily?) for gold, not bfd).

I use clang for linking and it calls ld.lld for this purpose.

On 11 May 2020, at 16:44, Denis Feklushkin via digitalmars-d-ldc wrote:
> I use clang for linking and it calls ld.lld for this purpose.

Could you please create an issue on GitHub with instructions to reproduce, or at least the full compiler/linker command lines? This discussion is getting quite hard to follow…

 — David

On Monday, 11 May 2020 at 15:58:13 UTC, David Nadlinger wrote:
> On 11 May 2020, at 16:44, Denis Feklushkin via digitalmars-d-ldc wrote:
>> I use clang for linking and it calls ld.lld for this purpose.
>
> Could you please create an issue on GitHub with instructions to reproduce, or at least the full compiler/linker command lines? This discussion is getting quite hard to follow…

Yes, but it will not be fast - the project is quite large, discussed command line is huge size (generated by Meson)

Linking comand line (LFs added to convient reading):

clang  -o firmware.elf
  'firmware.elf@exe/meson-generated_gpio.d.o'
  'firmware.elf@exe/meson-generated_freertos.d.o'
  [... huge amount of obj files skip ...]
  'firmware.elf@exe/subprojects_freertos_timers.c.o'
  'firmware.elf@exe/subprojects_libunwind_src_Unwind-seh.cpp.o'
  'firmware.elf@exe/subprojects_libunwind_src_UnwindRegistersSave.S.o'
  -L/usr/lib/gcc/arm-none-eabi/8.3.1/thumb/v7-m/nofp/ -Wl,--as-needed -Wl,--no-undefined
  -Xlinker --fatal-warnings -flto=thin -target thumbv7m-unknown-none-eabi
  --no-standard-libraries -Wl,
  --start-group subprojects/picolibc/semihost/libsemihost.a d/libdruntime.a
  subprojects/libopencm3/libopencm3_stm32f1.a subprojects/libopencm3/libreset_handler.a
  -Xlinker --script=linker_script.ld -lgcc -Wl,--end-group
  '-Wl,-rpath,$ORIGIN/subprojects/picolibc/semihost:$ORIGIN/d:$ORIGIN/subprojects/libopencm3'
  -Wl,-rpath-link,/home/denizzz/Dev/d_c_arm_test/builddir/subprojects/picolibc/semihost
  -Wl,-rpath-link,/home/denizzz/Dev/d_c_arm_test/builddir/d
  -Wl,-rpath-link,/home/denizzz/Dev/d_c_arm_test/builddir/subprojects/libopencm3
ld.lld: error: undefined symbol: _Dmodule_ref
>>> referenced by gpio.d
>>>               lto.tmp:(.text._D4gpio16__moduleinfoCtorZ+0x0)
>>> referenced by gpio.d
>>>               lto.tmp:(_D4gpio16__moduleinfoCtorZ)
>>> referenced by freertos.d
>>>               lto.tmp:(.text._D8freertos16__moduleinfoCtorZ+0x0)
>>> referenced by freertos.d
>>>               lto.tmp:(_D8freertos16__moduleinfoCtorZ)
>>> referenced by app.d
>>>               lto.tmp:(.text._D3app16__moduleinfoCtorZ+0x0)
>>> referenced by app.d
>>>               lto.tmp:(_D3app16__moduleinfoCtorZ)

ld.lld: error: undefined symbol: _d_run_main
>>> referenced by entrypoint.d:35 (/usr/lib/ldc/x86_64-linux-gnu/include/d/core/internal/entrypoint.d:35)
>>>               lto.tmp:(main)
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)

On Monday, 11 May 2020 at 15:58:13 UTC, David Nadlinger wrote:
> On 11 May 2020, at 16:44, Denis Feklushkin via digitalmars-d-ldc wrote:
>> I use clang for linking and it calls ld.lld for this purpose.
>
> Could you please create an issue on GitHub with instructions to reproduce, or at least the full compiler/linker command lines? This discussion is getting quite hard to follow…

Here is this project, ~master branch:
https://github.com/denizzzka/d_c_arm_test/

Problem solved!

It was not related to LDC. It was lead from mess-up of archievers ar, llvm-ar-7 and llvm-ar-9, which lead to creation of .a files what can't be readed properly by clang

Thanks to all who tried to help! :-)