On 7/1/22 12:11, Vinod KC wrote:
The following function is dimedll.testFunc:
> ```d
> module dimedll;
// ...
> export void testFunc() {
> writeln("This is from dll");
> }
> ```
We suspect the name of the file that defines main() is dime.d.
> extern void testFunc();
That symbol belongs
On Saturday, 2 July 2022 at 00:23:20 UTC, Ruby The Roobster wrote:
The solution is to remove the extern declaration. That does it
for me, and it prints the expected output. No need for a .def
file, unless you are using optlink as your linker (which, as a
matter of principle, you should use
The solution is to remove the extern declaration. That does it
for me, and it prints the expected output. No need for a .def
file, unless you are using optlink as your linker (which, as a
matter of principle, you should use lld or ld instead.)
On Friday, 1 July 2022 at 22:38:17 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 22:32:24 UTC, Vinod K Chandran wrote:
So using a `def` file is a must I think.
no it is not. you just need to mark things export and make sure
names match (including module name)
Thanks for the reply.
On Friday, 1 July 2022 at 22:32:24 UTC, Vinod K Chandran wrote:
So using a `def` file is a must I think.
no it is not. you just need to mark things export and make sure
names match (including module name)
On Friday, 1 July 2022 at 22:22:42 UTC, mw wrote:
Try follow instructions here:
https://wiki.dlang.org/Win32_DLLs_in_D
Thanks. So using a `def` file is a must I think. At first, I
thought I can skip that.
On Friday, 1 July 2022 at 21:15:50 UTC, Vinod K Chandran wrote:
On Friday, 1 July 2022 at 21:02:20 UTC, mw wrote:
I think the problem is the linker looking for dime.testFunc,
while your lib function is dimedll.testFunc
Thanks for the reply. What about this `mixin SimpleDllMain;` I
suspect
On Friday, 1 July 2022 at 21:02:20 UTC, mw wrote:
I think the problem is the linker looking for dime.testFunc,
while your lib function is dimedll.testFunc
Thanks for the reply. What about this `mixin SimpleDllMain;` I
suspect this.
On Friday, 1 July 2022 at 19:11:16 UTC, Vinod KC wrote:
Hi all,
I have created a dll file with this code.
```d
module dimedll;
export void testFunc() {
writeln("This is from dll");
}
```
void main() {
log("Lets build our own ime");
testFunc();
}
```
```
On Friday, 1 July 2022 at 20:08:45 UTC, ryuukk_ wrote:
I think it is `extern(D) void testFunc();`?
Thanks for the reply. But the result is same linker error.
I think it is `extern(D) void testFunc();`?
Hi all,
I have created a dll file with this code.
```d
module dimedll;
import core.sys.windows.windows;
import core.sys.windows.dll; // I don't what is this for.
import std.stdio;
mixin SimpleDllMain;
export void testFunc() {
writeln("This is from dll");
}
```
So now I have a dll fie named
On Friday, 1 July 2022 at 15:35:00 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
I has been using this pattern each time something needs
special treatment when it can be null:
i'd prolly check `static if(is(typeof(null) : T))` which means
if the null literal
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
I has been using this pattern each time something needs special
treatment when it can be null:
i'd prolly check `static if(is(typeof(null) : T))` which means if
the null literal implicitly converts to type T.
there's also the bludgeon
On Friday, 1 July 2022 at 13:53:28 UTC, Antonio wrote:
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
-Why?
I realized Json is an struct (not an object)... and I supose,
it is managing null asignation manually (as a way to build
Json(null)).
-Whats the correct whay to test if
On Friday, 1 July 2022 at 13:44:20 UTC, Chris Katko wrote:
It appears module access to a class is broken until the
constructor finishes.
No, it has nothing to do with the module. It's the reference
itself.
Until the constructor returns, the reference through which you're
constructing the
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
-Why?
I realized Json is an struct (not an object)... and I supose, it
is managing null asignation manually (as a way to build
Json(null)).
-Whats the correct whay to test if something can be null?
That's my question :-p
I has been using this pattern each time something needs special
treatment when it can be null:
```d
void doSomething(T)(T v)
{
import std.traits: isAssignable;
static if( isAssignable!(T, typeof(null))) {
if(v is null)
writeln("This is null");
else
writeln("This is not
On Friday, 1 July 2022 at 13:28:26 UTC, Chris Katko wrote:
...wait, does "world" not 'exist' until after the constructor
finishes? Is that's what's going on? But then why does it
'exist' when I send it directly? Is it only "registered" with
the module once this() finishes or something like
On Friday, 1 July 2022 at 13:12:05 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
D
bool initialize() //called from main
{
On Friday, 1 July 2022 at 13:20:15 UTC, Mike Parker wrote:
r.
And that also looks like the source of your original segfault.
You've got a circular reference going on in the constructors.
In other words, you're constructing a global world instance,
which in turn constructs an elf instance,
On Friday, 1 July 2022 at 13:01:30 UTC, Chris Katko wrote:
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called
elf.
So it's not a memory issue, but some sort of linkage issue.
world is null because the constructor
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called elf.
So it's not a memory issue, but some sort of linkage issue.
To add, I cannot even access g.world from inside elf's
constructor.
... which is the function that called it.
D
Thread 1 "main" received signal SIGSEGV, Segmentation fault.
objects.elf.this(g.pair, objects.atlasHandler) (this=, atlas=,
_pos=...) at ./src/objects.d:320
(gdb) bt
#0
dmd (but I think LDC also is affected)
this bug has bit me multiple times now, to the point I can
recognize it. Accessing module variables, from inside a method,
causes a segfault. Even if the variable should be available by
then through the call order. Proving that its a bug, you can
26 matches
Mail list logo
