Re: Comping a Musl-linked druntime & phobos?
On Thursday, 25 August 2022 at 01:52:15 UTC, Mathias LANG wrote: (snip) Hmmm... Maybe I don't understand. What exactly *is* Alpine Linux doing? That .patch file didn't contain anything substantial. It looks like it has some version of LDC on hand to use, probably already set up properly to use Musl. You're saying that you shouldn't need to pass in `-target` because if the compiler was compiled with `CRuntime_Musl`, it will just use that automatically. But that requires exactly what I don't have: a compiler that uses Musl. Am I missing something?
Comping a Musl-linked druntime & phobos?
Hi, all. Has anyone had any success compiling a Musl-linked druntime and phobos? I haven't had any luck so far. I'm running Linux Mint x64. Somewhat related - using `-target=x86_64-linux-musl` with dmd master doesn't even set the version `CRuntime_Musl`. I asked about this in the Discord, and I was told by Horo: dmd 2.096 worked well for me. Same for gdc, haven't tried ldc. There is/was a bug that was introduced recently in druntime that broke musl but the older versions should work fine 2.096 doesn't have the `-target` option, and 2.097.0-2.098.0 don't even build properly for me. Using LDC to build works of course, but only with `-betterC` (i.e. no druntime/phobos).
Re: dlang vs crystal-language
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote: On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Pros of **Crystal** 1. Attractive syntax. I like Ruby like syntax. It's really expressive. Cons of Crystal 1. It doesn't have a compiler for Windows. It uses WSL based compiler and I think it's a bad idea. I don't think I need to tell the pros & cons of **D lang** in it's own forum. BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea. I used tkD a long time ago. Look through [this repo](https://github.com/thegag96/codewrite) - maybe something in there will help you.
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? I've loved Sublime for years. I use it for everything, really. So pretty, so fast.
Details of the inline import idiom
I was looking back at the inline import idiom article[1]. One of the purported benefits of doing something like from!"std.datetime".SysTime was that doing so wouldn't go and import the entirety of the module into the namespace and slow down compile time / bloat the binary. But how is this so? When the template ends up doing import from = std.datetime, doesn't that go and import everything, not just SysTime? Or is there some detail I'm missing? Thanks! [1]: https://dlang.org/blog/2017/02/13/a-new-import-idiom/
Is DWT busted?
I'm sorry about bringing this into here instead of DWT's subforum, but it's somewhat dead and hasn't been getting a lot of attention. I decided to finally play around with DWT today and tried to build the example. I got this: Performing "debug" build using /usr/bin/dmd for x86_64. dwt:base 1.0.1+swt-3.4.1: target for configuration "library" is up to date. dwt 1.0.1+swt-3.4.1: target for configuration "linux-gtk" is up to date. main ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. Running ./main Program exited with code -11 I'm on Pop!_OS (basically Ubuntu), x64, DMD 2.079.0. Every library they ask for is installed. I tried cloning the source and building their snippets, and none of them work. Other people have apparently had this same problem for the past few months, and none of them find a solution. What's going on here? IDK if this is any help, but here's the backtrace according to gdb: https://pastebin.com/Xd46YwwP
Re: Dealing with the interior pointers bug
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: This comes from the fact that D's GC is conservative - if it sees something that *might* be a pointer, it assumes it *is* a pointer and thus had better not get freed. So is the GC then simply made to be "better-safe-than-sorry" or is this a consequence of how the GC does things? Or rather, does the GC know the type of any references to its memory at all? I suppose I should really ask if there's a document other than druntime's source that describes how the GC really works under the hood haha.
Dealing with the interior pointers bug
I saw this Tip of the Week a while ago (http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind of perplexed at it. It seems like a crazy potential bug... How exactly is the GC implemented that causes this problem to crop up? Does the GC just blindly scan memory until it finds pointers to heap memory to mark as "don't delete"? Could it ever be fixed?
Re: Porting Java code to D that uses << and >>> operators
On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote: From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". This is something I've never understood. Why doesn't DMD implement the behavior their own language reference specifies? It seems like a very nice guarantee to have...
Re: BinaryHeap crashes upon insertion if heapified with an array of length 1?
On Sunday, 9 April 2017 at 13:31:05 UTC, Michael Coulombe wrote: This is a bug in the insert method. I created a bug report for you and submitted a pull request for a fix: https://issues.dlang.org/show_bug.cgi?id=17314 Ah, so it is. Thanks!!
BinaryHeap crashes upon insertion if heapified with an array of length 1?
I'm trying to use a binary heap initialized with one element. However, this always seems to cause a range violation for some reason. This small example will do it: import std.stdio, std.container; void main() { auto pq = heapify([5]); pq.insert(8); } ...And it produces this error: https://pastebin.com/dyLNRz2W Oddly enough, if I heapify an array with any other length than 1, I can insert as much as I want (that includes an empty array!). Is this a bug in Phobos or some odd expected behavior? Thanks guys!
Re: Policy-based design in D
On Tuesday, 14 February 2017 at 10:05:19 UTC, TheFlyingFiddle wrote: (snip) Oh, I didn't know you could name mixin template instantiations like that! Thanks for the tip, that makes things work nicely!
Policy-based design in D
Tonight I stumbled upon Andrei's concept of policy-based design (https://en.wikipedia.org/wiki/Policy-based_design) and tried to implement their example in D with the lack of multiple inheritance in mind. https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate validation on dpaste fails right now?) The implementation isn't perfect, as I'm not sure how to check members of mixin templates so that you could verify whether print() and message() are actually where they should be. How would you do that? Is there any use for this kind of thing in D, and if so, what would it be? I've hardly dabbled in OOP patterns, but the abstraction seems kinda interesting.
Re: Strange memory corruption / codegen bug?
On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote: Try putting an `assert(childCrossPoint !is otherCrossPoint);` before the assignment. If it fails, the variables refer to the same node. That would explain how otherCrossPoint.left gets set. Ahh... This led me to it. I was about to say "That wouldn't be possible, childCrossPoint is part of a clone of the original caller!" But then I realized I did "this.getNodeList" towards the beginning instead of "child.getNodeList". I feel very silly right now, haha. Thanks for the help and your patience, guys.
Re: Strange memory corruption / codegen bug?
On Sunday, 11 December 2016 at 11:17:50 UTC, rikki cattermole wrote: Not public, please pastebin. https://github.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L135 I just put it on GitHub. No idea why the repo wasn't public even after I set it to be public...
Strange memory corruption / codegen bug?
I was porting my Evolutionary Computing homework written in Python over to D, and I've come across this bug I cannot for the life of me figure out. https://gitlab.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L139 I don't think I could cut this down to a smaller reproducible scenario due to how bizarre and specific this problem is, so I apologize in advance if this is hard to follow. Basically, imagine that I have a binary tree class where, due to how my program is set up, each node will have either children on both the left and right side or no children at all (the latter represented by a value of null for Tree's left and right member). I have a member function called "dup" -- marked const, mind you -- that just returns a deep copy of the tree and SHOULDN'T make any changes to the calling object. I call this function a couple different places and it appears to function okay, but at the spot I linked, if I call .dup here, it will corrupt one of the tree's nodes and put something in its left member for no apparent reason. This oddly doesn't happen on every Tree calling this function. This could definitely be some stupid mistake on my part, but the fact that calling a const-marked function changes the state of the calling object makes me think something else is afoot here... I would greatly appreciate anyone who would be willing to take a look at this. This bug is driving me absolutely nuts.
Re: A simplification of the RvalueRef idiom
On Tuesday, 22 November 2016 at 13:06:27 UTC, Nordlöw wrote: On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote: mixin template RvalueRef()// <-- DOES NOT TAKE A PARAMETER ANY MORE { alias T = typeof(this); static assert (is(T == struct)); @nogc @safe ref const(T) byRef() const pure nothrow return Why do you need to qualify `byRef` as pure nothrow when it's a template? The thing that gets me more is "return" as a function attribute. I see it under "MemberFunctionAttribute" in the grammar but I can't find an explanation for its use anywhere...
Re: strange -fPIC compilation error
On Monday, 31 October 2016 at 07:16:50 UTC, Sebastien Alaiwan wrote: Hello, From GCC 6.2, -fpie is becoming the default setting at compile and at link time. As dmd uses GCC to link, now the code needs to be compiled with a special option. Which means you need, at the moment, to add the following options to your dmd.conf: -defaultlib=libphobos2.so -fPIC (the change from GCC is related to security and address space randomization). So does this mean it's now impossible to compile statically until this gets fixed?
Re: Why can't static arrays be sorted?
On Saturday, 8 October 2016 at 21:14:43 UTC, Jon Degenhardt wrote: This distinction is a bit on the nuanced side. Is it behaving as it should? --Jon I think so? It's not being modified in the second case because the array is being passed by value... "x" there is a reference to an element of the copy created to be passed to each(). I assume there's a good reason why ranges in general are passed by value into these functions -- except in this one case, the stuff inside range types copied when passed by value won't be whole arrays, I'm guessing.
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 19:30:01 UTC, Jonathan M Davis wrote: It doesn't even make conceptual sense for a static array to be a range, because you can't remove elements from it. - Jonathan M Davis Interestingly enough, I found that using .each() actually compiles without the [] but (as expected) creates a copy... So, these output different values: thing.each!((ref x) => writeln()); thing[].each!((ref x) => writeln()); Should there me a more consistent behavior here? Even if the behavior is pretty undesired, why can the compiler consider it a range here but not .sort()?
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 02:19:13 UTC, Jonathan M Davis wrote: The problem is that static arrays aren't ranges (calling popFront on them can't work, because their length isn't mutable). However, you can slice a static array to get a dynamic array which _is_ a range. e.g. thing[].sort(); Just make sure that such a dynamic array does not outlive the static array, or it will refer to invalid memory (which would not be a problem in this case). - Jonathan M Davis Ah thanks guys. I think I just got used to thinking arrays would always be found to be ranges by the compiler. Good to know!
Why can't static arrays be sorted?
I was writing some code today and ran into this oddity that I'd never come across before: import std.algorithm : sort; int[10] arr = [0, 3, 4, 6, 2, 1, 1, 4, 6, 9]; thing.sort(); This doesn't compile. Obviously the .sort property works, but what about static arrays makes them unable to be sorted by std.algorithm.sort? Thanks.
Re: Can't use std.algorithm.remove on a char[]?
On Sunday, 1 May 2016 at 09:11:22 UTC, ag0aep6g wrote: It's because of auto-decoding. char[] is an array of chars, but it's been made a range of dchars. Calling front on a char[] decodes up to four chars into one dchar. Obviously you can't take the address of the dchar, because it's just a return value. You can't assign through front, because the number of chars could be different from what's currently there. The whole array would have to be re-arranged then, which would be unexpectedly costly for the user. The auto-decoding behavior was chosen to make dealing with char[] less bug-prone. With auto-decoding you don't have to worry about cutting a multibyte sequence in half (can still cut a grapheme cluster in half, though). However, as you see, it creates other headaches, and it's considered a mistake by many. Getting rid of it now would be a major breaking change. Could be worthwhile, though. That's a shame. I'd really like to be able to remove a character from a character array... I supplier I just have to get used to casting to ubyte[] or maybe just using dchar[] instead. I'm honestly surprised I haven't encountered this behavior sooner. It's interesting - as I keep coding in D and learning about how amazing it is to use, I always find these weird quirks here and there to remind me that it isn't flawless... I guess it can't be perfect, haha.
Re: Can't use std.algorithm.remove on a char[]?
On Saturday, 30 April 2016 at 19:21:30 UTC, ag0aep6g wrote: On 30.04.2016 21:08, Jon D wrote: If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. Characters are not the problem. remove works fine on a range of chars, when the elements are assignable lvalues. char[] as a range has neither assignable elements, nor lvalue elements. That is, lines 3 and 4 here don't compile: import std.range: front; char[] a = ['f', 'o', 'o']; a.front = 'g'; auto ptr = Why exactly is it like this? I would understand why strings (immutable character arrays) behave like this, but I feel like plain old character arrays should work the same as an array of ubytes when treated as a range... Or is there some other string-related behavior that would get broken by this?
Can't use std.algorithm.remove on a char[]?
I was just writing some code trying to remove a value from a character array, but the compiler complained "No overload matches for remove", and if I specifically say use std.algorithm.remove() the compiler doesn't think it fits any definition. For reference, this would be all I'm doing: char[] thing = ['a', 'b', 'c']; thing = thing.remove(1); Is this a bug? std.algorithm claims remove() works on any forward range...
Re: D and devkitARM
On Thursday, 10 March 2016 at 14:36:26 UTC, Nicholas Wilson wrote: Hmm. I apologise that this post is not in any logical order. dmd can only compile for x86 so you will have to use ldc or gdc makefiles are generally not used in d. you should be able to use the dub project settings file (dub.json or dub.sdl) to do most of the standard linking, as for some of the deeper magic I'm not sure. versioning: i'm not sure that d has a 3ds target version but it has an arm one. includes should not be an issue. If you cannot find bindings for ctru see if dstep can do it for you. I don't know what .v.pica or .shlist files are but you can use string imports to reference the data looks like the same idea can be used for the shader rule. However you may need to use a prehook script to call whatever "picassso" does first. Thanks for the suggestions. I know I need to use gdc, specifically the one found at ftp://ftp.gdcproject.org/binaries/devkitARM/ (or build it myself if this doesn't work for whatever reason). I'm starting to think a bigger problem aside from the Makefiles is just getting any D to compile with that gdc version at all. I'm pretty sure I need some sort of bare metal runtime. Would this be something that could work, or should I look elsewhere? https://bitbucket.org/timosi/minlibd ...This probably really is above my knowledge level, but I suppose I'll never learn if I don't give it a shot. Like I said, if anyone has any sort of advice on how I should approach this, I'd be happy to hear it.
D and devkitARM
Hi guys, for a possibly-in-over-my-head project I'd like to get working a simple "Hello World" type program in which I call a D function from C in a 3DS homebrew app (or maybe even have it all in plain D with bindings to libctru). The thing is, I'm not skilled with Makefiles so I don't have a clue on how to correctly set up the toolchain for linking everything. I can compile some D-calling C code just fine with dmd and gcc on Linux (though I can't get anything working with gdc for whatever reason). Would anyone be able to point me in the right direction? This is the example Makefile for a 3DS homebrew app: http://pastebin.com/fcJrrMg9 It seems like there would be issues differentiating the .d build definition files from D source files... Thanks!
TreeViews in tkd
I've been trying to get into tkd to make some GUI apps, since it looked like the simplest/intuitive library out there so far. I've been attempting to use their TreeViews to make interactable lists of things, but it almost looks like there's some missing functionality. For example, I'm not sure there are any ways to delete individual rows from one. You can clear them all entries, but there doesn't look to be a method for just getting rid of one row - if there is, I can't find it. Calling destroy() on an individual row does not remove it either (yet apparently destroy() effects the GUI in tkd, not just finalizing the object). It also doesn't look like there's a way to get a row by an index or ID, either. You can get columns... But the only way you can a row object is through getSelectedRows(). Am I missing something here? I made an issue on GitHub but I'm not sure I'll get anything back, it's been 9 months since the last commit. Has anyone worked with this before and could give me some tips? Thanks!
Re: TreeViews in tkd
On Thursday, 17 December 2015 at 11:33:31 UTC, Gary Willoughby wrote: On Thursday, 17 December 2015 at 09:47:42 UTC, TheGag96 wrote: I've been trying to get into tkd to make some GUI apps, since it looked like the simplest/intuitive library out there so far. I've been attempting to use their TreeViews to make interactable lists of things, but it almost looks like there's some missing functionality. I made an issue on GitHub but I'm not sure I'll get anything back, it's been 9 months since the last commit. Has anyone worked with this before and could give me some tips? Thanks! Calm down, lol. There have been no commits for 9 months because as far as i'm aware it's finished and stable. I got your issue this morning and will take a look tonight after work. Ah thanks, sorry for my impatience. I guess it's good the D community is so tight-knit that everyone lurks these forums, haha.
Re: conver BigInt to string
On Thursday, 5 November 2015 at 16:45:10 UTC, Meta wrote: The second issue is that using .sort instead of .sort() (note the parentheses) calls the built-in sort instead of std.algorithm.sort, which is strongly discouraged. You should always use std.algorithm.sort over the built-in sort, which you can do just by appending those parentheses. Whoa whoa whoa... This is the first time I've heard about this difference, and I've used .sort plenty of times... That seems like really, REALLY bad design, especially considering the language allows functions to be called without parentheses. I thought I was using std.algorithm's version the whole time. What's the difference between the implementations of arrays' .sort property and std.algorithm.sort()? And does sort() throw out that "unable to deduce function argument" error for a character array of all things?
Re: Array of BitArrays definition compiles in DMD but not in GDC.
On Friday, 9 October 2015 at 07:08:15 UTC, John Colvin wrote: On Thursday, 8 October 2015 at 21:40:02 UTC, TheGag96 wrote: [...] gdc is a bit out of date at the moment. If you do something like this: auto bitArray(bool[] ba) pure nothrow { BitArray tmp; tmp.init(ba); return tmp; } auto bitArray(void[] v, size_t numbits) pure nothrow { BitArray tmp; tmp.init(v, numbits); return tmp; } then replace all your calls to the constructor BitArray with bitArray, things should work OK for you. That appears to work, although the compiler was complaining that the calls to init were not pure nor nothrow. Thanks! Hopefully they'll update GDC soon.
Array of BitArrays definition compiles in DMD but not in GDC.
In my code I'm passing an array of BitArrays to a constructor like this (though mostly as a placeholder): Terrain t = new Terrain(1, 15, [ BitArray([1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]), BitArray([1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1]), ]); The code compiles fine when using DMD 2.068.1 but GDC 5.2.1, I get this error for every line: error: cannot implicityly convert expression ([stuff]) of type int[] to ulong Why does this compiler difference exist and how do I get around it? Thanks!
I can't get passing an array by reference to work anymore...
So I'm just doing a small test program here: http://pastebin.com/UYf2n6bP (I'm making sure I know quicksort for my algorithms class, I know functionally this won't work as-is) I'm on Linux, 64-bit, DMD 2.068.1, and when I try to compile this I'm getting: quicksort.d(18): Error: function quicksort.quickSort (ref int[] arr) is not callable using argument types (int[]) quicksort.d(19): Error: function quicksort.quickSort (ref int[] arr) is not callable using argument types (int[]) No matter how I attempt to define the array test, it will never allow me to pass it by reference no matter what. I even copy-pasted some example code from here (https://en.wikibooks.org/wiki/D_(The_Programming_Language)/d2/Pointers,_Pass-By-Reference_and_Static_Arrays#Pass_By_Reference, bottom of the page), and it gave the same error. What's the problem here? I SWEAR I've passed arrays by reference before just like this. Thanks guys.
Re: Example from d-idioms is incorrect
On Thursday, 30 April 2015 at 22:01:43 UTC, Justin Whear wrote: On Thu, 30 Apr 2015 21:30:34 +, TheGag96 wrote: Was the behavior of the remove() function changed recently? Thanks guys. I believe remove has always worked this way. What you're seeing is explained by this note in the documentation for remove: The original array has remained of the same length because all functions in std.algorithm only change content, not topology. The value 8 is repeated because std.algorithm.move was invoked to move elements around and on integers move simply copies the source to the destination. To replace a with the effect of the removal, simply assign a = remove(a, 1). The slice will be rebound to the shorter array and the operation completes with maximal efficiency. Ah... This is all a lot clearer now. Thanks guys!
Example from d-idioms is incorrect
I was looking at the d-idioms website today and saw this code example: http://p0nce.github.io/d-idioms/#Adding-or-removing-an-element-from-arrays And I was kind of irked. I just recently working with removing an element from an array in a small project I worked on two weeks ago, and I had to learn the hard way that to properly remove an element from an array in the way this example describes, you have to do array.length--; as well. This code: import std.stdio, std.algorithm; void main() { int[] arr; //ensuring it's dynamic arr ~= 1; arr ~= 5; arr ~= 10; arr.remove(1); writeln(arr); writeln(arr == [1, 10]); arr.length--; writeln(arr); writeln(arr == [1, 10]); } produces this output: [1, 10, 10] false [1, 10] true Compiled and ran on Windows, dmd v2.067.0. Unless I'm totally missing something here, that website is giving some pretty wrong information... Was the behavior of the remove() function changed recently? Thanks guys.
Re: Reading whitespace separated strings from stdin?
On Tuesday, 21 April 2015 at 03:44:16 UTC, weaselcat wrote: snip Wow, that's a damn good solution... I didn't know that readln() could take an argument that it stops at once it finds. Now the thing is, this program is supposed to be a reverse Polish notation calculator. A human using this program would probably be confused as to why nothing happens when they hit enter after a line -- it only really works in the context of copying and pasting the whole input in. Still a really neat solution to know anyhow. Thanks!
Reading whitespace separated strings from stdin?
Hi guys! I had this homework assignment for data structures that has a pretty easy solution in C++. Reading input like this... 1 2 3 # $ 4 3 * ! # 20 3 / # $ # 62 # $ 2 3 8 * + # 4 48 4 2 + / # SUM # $ 1 2 3 4 5 # R # @ ...where @ denotes the end of input is fairly simple in C++: string token = ; while (token != @) { //handle input } Note that having newlines doesn't matter at all; every token is just assumed to be separated by whitespace. However in D, I looked around could not find a solution better than this: foreach (line; stdin.byLine) { foreach (token; line.split) { //handle input } } Is there any way to do this without two loops/creating an array? readf( %d, token); wasn't cutting it either. Thanks.
Re: Reading whitespace separated strings from stdin?
On Tuesday, 21 April 2015 at 01:46:53 UTC, Adam D. Ruppe wrote: I think this should work: import std.stdio; void main() { string token; while(readf(%s , token)) writeln(token); } Have you tried that? What is wrong with it if you have? It'll just leave some trailing whitespace, which I don't want. And somehow doing token = token.stip STILL leaves that whitespace somehow...
Linking C++ standard library works with GDC... but not DMD. (Linux)
Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks.
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 09:46:40 UTC, John Colvin wrote: On Thursday, 16 April 2015 at 08:51:15 UTC, TheGag96 wrote: Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks. I don't know why that's happening, but you can explicitly link using gcc (or ld/gold directly) if you need to. E.g. dmd -c myFile.d gcc myFile.o -lphobos2 or whatever is necessary on your project/system. I had wanted to try this too, but I wasn't sure if the linker knew where phobos2 was on my system. I just tried this now for funsies: dmd -c *.d g++ main.o [client files] -lphobos2 With or without that -lphobos2 flag, I get errors like these: main.d(.text._Dmain+0x18e): undefined reference to `D3std5stdio16__T7writeln(TAyaZ7writeFAyaZv'
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 12:57:12 UTC, Steven Schveighoffer wrote: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) Try dmd -v to tell you exactly what command it is running for link. Then play around with the link line to see if you can figure out a way to link it correctly. We can work on fixing the situation from there. Maybe there's a way to link using dmd, maybe we have to fix dmd so it allows the correct link call. -Steve Got it!! This is what helped me the most. I compiled a regular C++ program with the -v flag, found where my libstdc++.a was, added it to the command and bam. I really should have thought of this one earlier... Thanks for the quick support, everyone!