Either I'm confused or the gc is

user1234 user1234 at 12.de
Thu Oct 22 22:05:42 UTC 2020


On Thursday, 22 October 2020 at 19:38:42 UTC, donallen wrote:
> On Thursday, 22 October 2020 at 18:54:24 UTC, tsbockman wrote:
>> On Thursday, 22 October 2020 at 04:02:10 UTC, donallen wrote:
>>> I tried this. With the gc on, the problem still occurs.
>>>
>>> I am working on 64-bit Arch Linux systems, up-to-date, DMD64 
>>> D Compiler v2.094.0
>>
>> Have you tried using a different compiler?
>
> Yes -- to no avail:
> dca at franz:~/Software/newcash_d/verifier$ make
> cd ../library ; make
> make[1]: Entering directory 
> '/home/dca/Software/newcash_d/library'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory 
> '/home/dca/Software/newcash_d/library'
> #dmd -g -profile=gc -I=../library -L='-lsqlite3' verifier.d 
> ../library/lib.o
> ldc -g -I=../library -L='-lsqlite3' verifier.d ../library/lib.o
> ../library/lib.o:lib.d:function 
> _D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyamMAxaZv: 
> error: undefined reference to '_d_throwdwarf'
> ../library/lib.o:lib.d:function [...]

The errors you get are because you must compile *everything* with 
ldc (program name should be ldc2 BTW), but the lib.o file is 
still produced with dmd as it contains DMD specific symbols.

> I hate to say this, because so much of this project makes sense 
> to me -- the design of the language, the effort that has been 
> put into documentation, the helpfulness of the community -- but 
> I think I have to throw in the towel. I can't spend any more 
> time on this and it appears that D is just not solid enough for 
> the work I'm trying to do with it.

Yeah, that's perfectly understandable.

As you've been said in one of the first answer this must be 
because D GC sees a pointer allocated with malloc, and this 
pointer looks orphan to the GC as it has no root.

Would you put something that's mallocated in a D struct or in a D 
array ?
 From the memory point of view the code you have shown is correct 
(the `fromStringz().dup` is exactly what's must be done to 
prevent problems when mixin manual and D managed memory) so the 
origin of the problem really *has* to be somewhere else.


More information about the Digitalmars-d mailing list