Re: How can I use ldc2 and link to full runtime on arm with no OS
On Wednesday, 21 June 2017 at 15:45:32 UTC, David Nadlinger wrote: On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote: when trying to compile I'm getting lots of errors like this one: C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: module config is in file 'gc\config.d' which cannot be read import path[0] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc import path[1] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import Build Failed any ideas what could be the cause? You are not adding druntime/src to the import path. I'd suggest you focus on other things first, though. Having D's GC on a platform with less than 1 MiB RAM is a rather sketchy proposition. — David My idea is to build the whole thing, see what the code size and performance is, and then one by one reduce things down as needed. Starting from nothing so far has been a bit of a none starter!
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 19:44:46 UTC, kinke wrote: [...] when trying to compile I'm getting lots of errors like this one: C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: module config is in file 'gc\config.d' which cannot be read import path[0] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc import path[1] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import Build Failed any ideas what could be the cause? and also: LLVM ERROR: unsupported relocation on symbol [CC 9/164][druntime]convert.d Build Failed LLVM ERROR: unsupported relocation on symbol after changing flags to: -c -O0 -lib -betterC -release -boundscheck=off -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Tuesday, 20 June 2017 at 19:44:46 UTC, kinke wrote: On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote: How do I link in the run time and gc, etc? In your case, you firstly need to cross-compile druntime to your target. This means compiling most files in the src subdirectory of LDC's druntime [1], excluding obvious ones like src\test_runner.d, src\core\sys, src\core\stdcpp etc. There are also a bunch of C and assembly files which need to be cross-compiled with a matching gcc. You'll need to do this manually via something along these lines: cross-gcc -c <.c files and .asm/S files> ldc2 -mtriple=... -lib -betterC -release -boundscheck=off <.o files generated above> -of=libdruntime.a Then try linking your minimal code against that druntime (and static C libs, as druntime is built on top of the C runtime, see [2]). Depending on what features you make use of in your code, you'll need to patch linked-in druntime modules to remove the OS dependencies and possibly reduce the C runtime dependencies as well. [1] https://github.com/ldc-developers/druntime. [2] http://forum.dlang.org/thread/mojmxbjwtfmioevuo...@forum.dlang.org when trying to compile I'm getting lots of errors like this one: C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: module config is in file 'gc\config.d' which cannot be read import path[0] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc import path[1] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import Build Failed any ideas what could be the cause?
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 08:38:21 UTC, Nicholas Wilson wrote: On Tuesday, 20 June 2017 at 14:12:36 UTC, Dan Walmsley wrote: Firstly who do we need to talk to about the bloat in LDC? I'll be happy to help with the LDC stuff once I hand in my Honours thesis on the 3rd of July, just ask on https://gitter.im/ldc-developers/main or send me a message on gitter. whats your gitter handle?
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote: On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: [...] The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. [...] Mike, is there an email address I can contact you outside the forum?
Re: What is the state of Microcontroller support in d?
On Wednesday, 21 June 2017 at 00:50:35 UTC, Mike wrote: On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: [...] The more I think about this, the more it seems like the best approach. All this time I've been trying to find a way to build just enough runtime code to support the features I'm using, and I've only encountered frustration. It's a shame that we have to build such a massive amount of infrastructure just to get a build, only to have the linker strip it all away, but apparently that's just the way things are. Forget -betterC and -no-rtti; embrace it all! We might just be be able to turn this lemon into lemonade afterall. I'm having a bit of a change of heart (or maybe there's something in my coffee). I'll be traveling overseas for the next month, so when I return I'll revisit this and see if it still appeals to me. Mike When iv been using c++ on stm32 I have had to rely on gcsections to produce a workable binary. Have a good holiday, ill try as much as I can to improve things in the mean time 😀
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote: [...] Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. [...] Mike, I was thinking if you had used memory mapped structs instead of classes you probably wouldn't have come up across the rtti bloat so hard and it although be annoying wouldn't have been a show stopper, was there a particular reason to use classes to represent the registers? Dan
How can I use ldc2 and link to full runtime on arm with no OS
I'm starting to make attempts to find out what is needed to make D finally work on low level embedded targets. I have been using LDC2, i compile each .d file to and .o file and link using arm-none-eabi-gcc. I have a demo available here: Www.github.com/vitalelement/stm32dblinky includes a linked script. I was originally trying to have a minimal run time approach but having read a lot here I don't buy the argument that these targets cant run with GC. So id like to now link to the full run time if possible and try out the GC. However there doesn't seem to be any guide on how to do this? I need to know, how does the run time know which area of ram to use for heap? In c/c++ usually we use linked script to provide an area of ram for this. How do I link in the run time and gc, etc? Many thanks Dan
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote: If we push to have this fixed after that we are pretty close to having something usable are we not? Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there. If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it. But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way. Mike I completely agree with you here, its a real shame! Id be happy to put some effort into this, I don't know if you can help me put pressure on the right people to get the bloat thing fixed. It seems like its probably fixed in dmd compiler, but none of the others. I think ldc2 is the compiler that has the most potential because it can easily be compiled unlike the gdc one and then dmd one doesn't seem to support arm out the box unless things changed recently. I'm happy to have a GC on a system like stm32, as I read it only collects on calls to new, and most sensible embedded designs would just allocate at initialization and not during runtime. Threading I think we could easily use freertos or something underneath. Which just leaves dynamic arrays and exceptions which I know next to nothing about right now :) Firstly who do we need to talk to about the bloat in LDC?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:35:38 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] The C++ bindings should be opt-in.. [...] Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause! [...] That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time! I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP. Ignoring the bloat issue before, any ideas why I might be getting hard fault when trying to create object on the stack?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] The C++ bindings should be opt-in.. [...] Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause! [...] That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time! I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:22:42 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote: [...] The bloat is still there, but for some reason it's in the .text section. [...] damn! If we push to have this fixed after that we are pretty close to having something usable are we not?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:00:28 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote: https://github.com/vitalElement/STM32DBlinky I don't see the linker script sorry, committed linker script now :)
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. https://github.com/vitalElement/STM32DBlinky commands to build were: Compile: ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release main.d -ofmain.o ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release stm32f4xx_startup.d -ofstm32f4xx_startup.o Link: arm-none-eabi-gcc -mcpu=cortex-m4 -Wl,-Map,output.map -nostdlib -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nostartfiles -Wl,--gc-sections -O0 -Wl,-T"link.ld" -oBlinky.elf attribute.o object.o main.o stm32f4xx_startup.o -Wl,--start-group -Wl,--end-group If you need windows binaries for arm-none-eabi I can give you some.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. https://github.com/vitalElement/STM32DBlinky
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. I'm going to shove it in a GitHub repo give me 10 mins.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:
On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime
experiment:
https://github.com/JinShil/minimal_druntime_experiment
Mike
Mike,
I think good news:
I built a slightly different example, because I don't have
access to the linker you have, I just had the arm-none-eabi one
and I used ldc 1.3.0-beta2.
I compiled using these flags:
-march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g
-defaultlib= -conf= -oftest -better
and I got 0 rodata no rtti (I did do -gc-sections) if I don't
gc-sections it complains about loads of missing runtime stuff.
I tried then to instantiate a class, but it just crashes in
hardfault:
final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }
extern (C) void _d_callfinalizer (void *p)
{
}
class Point
{
this (int x, int y)
{
X = x;
Y = y;
}
int X;
int Y;
}
void Main()
{
scope p = new Point(2,2);
p.X = 1;
p.Y = 1;
int x = 0;
x++;
}
Perhaps D needs to be aware of my stack? I will take a look at
your linker script. But at least there is 0 type info data
after -gc-sections has run.
Actually about the stack was a red herring the code did actually
work!
my only issue is now when I add a method I get:
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function
`_D4main5Point3SumMFZi':
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference
to `_D9invariant12_d_invariantFC6ObjectZv'
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference
to `_d_assert_msg'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function
`_D4main4MainFZv':
C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference
to `_d_eh_resume_unwind'
Whats the invariant object thing?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime
experiment:
https://github.com/JinShil/minimal_druntime_experiment
Mike
Mike,
I think good news:
I built a slightly different example, because I don't have access
to the linker you have, I just had the arm-none-eabi one and I
used ldc 1.3.0-beta2.
I compiled using these flags:
-march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g
-defaultlib= -conf= -oftest -better
and I got 0 rodata no rtti (I did do -gc-sections) if I don't
gc-sections it complains about loads of missing runtime stuff.
I tried then to instantiate a class, but it just crashes in
hardfault:
final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }
extern (C) void _d_callfinalizer (void *p)
{
}
class Point
{
this (int x, int y)
{
X = x;
Y = y;
}
int X;
int Y;
}
void Main()
{
scope p = new Point(2,2);
p.X = 1;
p.Y = 1;
int x = 0;
x++;
}
Perhaps D needs to be aware of my stack? I will take a look at
your linker script. But at least there is 0 type info data after
-gc-sections has run.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 09:36:54 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote:
Regarding not being able to --gc-sections, perhaps this was
fixed in LDC?
http://forum.dlang.org/post/cxjubpxxknlkqvdgy...@forum.dlang.org
My last test with LDC is here:
https://issues.dlang.org/show_bug.cgi?id=14758#c14
Try to get that code to compile with LDC and let me know what
`objdump -s -j .rodata test` gives you.
Mike
No longer compiles:
"Error: Missing class declaration: ModuleInfo
Please check that object.di is included and valid"
So I add
`
struct ModuleInfo
{
}
`
but then ldc crashes...
added an issue here:
https://github.com/ldc-developers/ldc/issues/2174
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 08:48:05 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? [...] Regarding not being able to --gc-sections, perhaps this was fixed in LDC? http://forum.dlang.org/post/cxjubpxxknlkqvdgy...@forum.dlang.org
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote: Hi you still around, I'm starting to investigate these issues and see if I can start using D in some of my embedded projects at my company. I've got stuck at the hurdle of trying to use minilibd with Ldc compiler, did you make progress since this post?, IMO microcontroller support in D is only slightly better than non-existent. I tried about 2 or 3 years ago to move the ball forward on it, but just ran into way too many obstacles. The nail in the coffin for me was https://issues.dlang.org/show_bug.cgi?id=14758. To enumerate some of the problems (I don't have the energy for an exhaustive list, so these are just off the top of my head at the moment) 1. Compiler-runtime coupling. The compiler expects too much of the runtime to exist even when what it requires has no hope of ever being executed in the resulting binary. So, it forces us to implement silly hacks and stubs just to get a build. 2. The compiler adds things that aren't even needed in the resulting binary, and does so in a way that prevents --gc-sections and LTO from removing them. For some of my code, the binary was so large it wouldn't even fit on the microcontroller's flash memory. 3. Many of the veterans in the D community support the current dependency the runtime has on C standard library bindings, stating that they are required (which is not true). Furthermore, they want to make the problem worse by adding C++ standard library bindings as well. I submitted pull request to begin moving these bindings to Deimos, and make the dependencies private for individual platforms' ports, but only encountered resistance and misunderstanding. 4. The D gatekeepers have become very averse to anything that would cause too much disruption, making me believe that the fundamental changes that are needed to make microcontroller programming in D a reality will never be accepted. 5. Too many pull requests sit in "purgatory" for way too long without any progress. I believe that trying to move my changes forward would be an uphill battle, and ultimately not worth the frustration. 6. Rust has "minimal runtime" as one of the pillars of its language design philosophy. You can truly pay-as-you go while you build your system. This is how it should be, and unless you're looking for a fight, you'll probably be better off there: http://blog.japaric.io/quickstart/. That's where I'm allocating my resources these days. Mike How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? I was so hopeful for D when I saw how nice the syntax is, I saw rust and I didn't get the same feeling, not that I wont give it a chance, I just feel as you know embedded systems is dominated by C and C++ and D seems closer to those than Rust. To be fair I was impressed with the -betterC flag and that actually looks nice I you just want a C replacement but no classes, etc. I have not been able to get even a minimal project to compile when a class is introduced `Error: Missing class declaration: TypeInfo_AssociativeArray` Will take a look at rust, but would be keen to know if you could be motivated by the SystemD / EmbeddedD idea?
Re: What is the state of Microcontroller support in d?
On Friday, 8 April 2016 at 03:38:01 UTC, Taylor Hillegeist wrote: So, for me one of the greatest things about d is that it is compiled to machine language. But It makes me sad that this strength doesn't seem to be available in one of the most obvious places. [...] Hi you still around, I'm starting to investigate these issues and see if I can start using D in some of my embedded projects at my company. I've got stuck at the hurdle of trying to use minilibd with Ldc compiler, did you make progress since this post?,
Embedded Systems (STM32) LDC Absolute minimal runtime
Hi guys, I run an open source project developing a modern cross platform IDE for embedded systems, https://github.com/VitalElement/avalonStudio (perhaps the IDE could complement D as I have not found many just works out the box solutions for D yet.) I have begun to integrate the LDC compiler and would also like to attempt to use D in an upcoming embedded project I have. I have played around with the betterC flag and it looks promising. I would also like to have use of classes, however as soon as I try to use a class I get many link errors. see below: The undefined reference to `_d_dso_registry' comes from removing the -betterC flag. I understand these other symbols would be provided by object.d, however I am unable to find an object.d that will compile on LDC, and ideally a minimal implementation. Can anyone help? C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main9TestClass3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `ldc.register_dso': C:\dev\repos\STM32DBlinky\Blinky\main.d:(.text.ldc.register_dso+0x60): undefined reference to `_d_dso_registry' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x4): undefined reference to `_D6object6Object8toStringMFZAya' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x8): undefined reference to `_D6object6Object6toHashMFNbNeZk' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0xc): undefined reference to `_D6object6Object5opCmpMFC6ObjectZi' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x10): undefined reference to `_D6object6Object8opEqualsMFC6ObjectZb' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestClass7__ClassZ]+0x0): undefined reference to `_D14TypeInfo_Class6__vtblZ' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestClass7__ClassZ]+0x28): undefined reference to `_D6Object7__ClassZ'
