Re: How can I build dynamic library with ldc in termux?
On Sunday, 3 March 2019 at 01:47:50 UTC, Domain wrote: /data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -lphobos2-ldc-shared /data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -ldruntime-ldc-shared Any dub config example? ~> dub build Dynamic libraries are not yet supported as dependencies - building as static library. Performing "debug" build using /data/data/com.termux/files/usr/bin/ldc2 for aarch64, arm_hardfloat. dll:so ~master: target for configuration "library" is up to date. dll ~master: building configuration "application"... /data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -lphobos2-ldc-shared /data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -ldruntime-ldc-shared clang-7: error: linker command failed with exit code 1 (use -v to see invocation) Error: /data/data/com.termux/files/usr/bin/gcc failed with status: 1 /data/data/com.termux/files/usr/bin/ldc2 failed with exit code 1.
How can I build dynamic library with ldc in termux?
/data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -lphobos2-ldc-shared /data/data/com.termux/files/usr/bin/aarch64-linux-android-ld: cannot find -ldruntime-ldc-shared
Re: Error 42: Symbol Undefined __D3std7process10spawnShellFNeMAxaMxHAyaAyaEQBpQBo6ConfigMQBbMQzZCQClQCk3Pid
Ok, seems to be related to an older installed DMD 2.079.0, updating to 2.085.0 fixed the problem. Robert On 2019-03-02 21:15:05 +, Robert M. Münch said: Hi, trying to compile some stuff on Windows and get a bunch of undefined symbol errors, but these look as some standard modules are missing. See full output at: https://pastebin.com/e9xLrQAF Any idea how this can happen? Or how to fix this? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Error 42: Symbol Undefined __D3std7process10spawnShellFNeMAxaMxHAyaAyaEQBpQBo6ConfigMQBbMQzZCQClQCk3Pid
Hi, trying to compile some stuff on Windows and get a bunch of undefined symbol errors, but these look as some standard modules are missing. See full output at: https://pastebin.com/e9xLrQAF Any idea how this can happen? Or how to fix this? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Struct destructor
On Saturday, March 2, 2019 4:32:53 AM MST JN via Digitalmars-d-learn wrote:
> Compare this D code:
>
> import std.stdio;
>
> struct Foo
> {
> ~this()
> {
> writeln("Destroying foo");
> }
> }
>
> void main()
> {
> Foo[string] foos;
>
> foos["bar"] = Foo();
> writeln("Preparing to destroy");
> foos.remove("bar");
> writeln("Ending program");
> }
> D results in:
>
> Preparing to destroy
> Ending program
> Destroying foo
>
> Is this proper behavior? I'd imagine that when doing
> foos.remove("bar"), Foo goes out of scope and should be
> immediately cleaned up rather than at the end of the scope? Or am
> I misunderstanding how should RAII work?
foos is an associate array. Its memory is managed by the GC. As such, any
objects in the AA will only have their destructors run when the GC collects
the memory. If no collection happens, then the destructors will never
actually be run. Given that you're seeing the output from the destructor
after main executes, it looks like the GC is currently set up to do a
collection when the program terminates (though that's not actually
guaranteed to happen by the language). If no collection were run, then
you'd just see
Preparing to destroy
Ending program
But either way, remove doesn't trigger a collection. It has no reason to.
Whatever memory the AA has which contains the Foo is either still referenced
by the AA after remove is called, or it's unreferenced but hasn't been
collected by the GC, because no collection has been run. It wouldn't
surprise me if the AA actually overwrote the Foo with Foo.init when remove
was called, in which case, opAssign would have been called if you'd defined
it, but you didn't, and I'm not familiar with the AA implementation's
internals, so I don't know exactly how it currently works. But regardless of
whether the AA would have reused the memory, or whether it was no longer
referenced and was just waiting for the GC to run a collection, without the
GC running a collection, the destructor would not be run. Since the GC ran a
collection as part of the program's shutdown after main ran, the memory was
collected at that point, and the destructor was run, causing the
destructor's message to be printed after main terminated.
The GC heap really is no place for objects that need deterministic
destruction, because you don't normally know when the GC will run a
collection. It works well enough if you don't care when the object gets
collected, but if you really need deterministic destruction, then the object
needs to be on the stack, or you need to manage its memory manually, with
its memory being allocated by something other than the GC.
- Jonathan M Davis
Re: Struct destructor
On Saturday, 2 March 2019 at 11:32:53 UTC, JN wrote:
...
Is this proper behavior? I'd imagine that when doing
foos.remove("bar"), Foo goes out of scope and should be
immediately cleaned up rather than at the end of the scope? Or
am I misunderstanding how should RAII work?
https://dlang.org/spec/struct.html#struct-destructor
"Destructors are called when an object goes out of scope. Their
purpose is to free up resources owned by the struct object."
Example:
import std.stdio;
struct S
{
~this()
{
import std.stdio;
writeln("S is being destructed");
}
}
void main(){
{
S s = S();
scope (exit)
{
writeln("Exiting scope");
}
}
writeln("Ending program.");
}
Output:
Exiting scope
S is being destructed
Ending program.
Matheus.
Struct destructor
Compare this D code:
import std.stdio;
struct Foo
{
~this()
{
writeln("Destroying foo");
}
}
void main()
{
Foo[string] foos;
foos["bar"] = Foo();
writeln("Preparing to destroy");
foos.remove("bar");
writeln("Ending program");
}
and equivalent C++ code:
#include
#include
#include
using namespace std;
struct Foo
{
~Foo()
{
cout << "Destroying foo" << endl;
}
};
int main()
{
map foos;
foos["bar"] = Foo();
cout << "Preparing to destroy" << endl;
foos.erase("bar");
cout << "Ending program" << endl;
}
C++ results in:
Destroying foo
Preparing to destroy
Destroying foo
Ending program
D results in:
Preparing to destroy
Ending program
Destroying foo
Is this proper behavior? I'd imagine that when doing
foos.remove("bar"), Foo goes out of scope and should be
immediately cleaned up rather than at the end of the scope? Or am
I misunderstanding how should RAII work?
