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