[aldacron]

I've finally gotten around to using DerelictIL in a project and I'm having trouble with it. Every time I call ilGenImages I get an Access Violation:

[JJR]

Sometimes the library is not compiled with Windows calling convention even on windows (this was the case with gtk on windows). Did you check to see whether changing the linkage to extern(C) worked for these functions? THe DevIL library might not be compiled with stdcall modifiers in the dll.

Some functions will still run with extern(Windows) decorating them even if they are intrinsically extern(C), but eventually one of them will crash horribly.

Just a thought.

-JJR

[aldacron]

Yeah, actually I did try that and it didn't make a difference. But also, looking at the devil header file they use the __stdcall calling convention (which is what extern(Windows) is). This one's really a head scratcher.

[aldacron]

I put this on the back burner thinking I'd revisit it later. Now, I am having the same problem with DerelictSDL. So far, I've only found it to occur with SDL_GL_SetAttribute. I haven't tested it with many other functions, but the ones I have worked fine - with the exception that SDL_WM_SetCaption is ignoring the value I pass for a window title. This appeared out of the blue when I rebuilt another project I had been working on before.

To recap, what's happening with SDL_GL_SetAttribute is the same behavior I saw when calling ilGenImages. Calling the function results in an Access Violation even though the function pointer is non-null and was successfully loaded by Derelict. Now with SDL_WM_SetCaption failing to work when it did just two weeks ago in the same project, I'm more stumped than ever.

Perhaps it's something related to one of the recent DMD releases? I was using a freshly built derelictSDL.lib, so I replaced it with one I built two months ago with a different DMD version. The problem persisted. So if it is a DMD issue it's something that occurs at the call site. Or it could be a linker issue. Has the linker been updated recently?

Whatever it is that's causing this it's really throwing a monkey wrench into my current plans. Is there anyone else who can reproduce this?

[JJR]

Strange.

Has this problem been occurring since you started using the build tool?

Another thought...

If you don't compile Derelict to a library... say, just compile in all object files from derelict and your project, perhaps manually... do you find the problem still exists?

I have experienced wierd problems (ie program crashes) on linux (with or without build, I've now determined) if I include a library on the commandline with the -L-l switch. Apparantly the linking is totally messed up with this method of including libraries (which may also relate to pragma(link,...) directives too). While the linker knows how to find them with the -L-l switch (with the dmd.conf setup appropriately), it includes the libraries in such a manner that conflicts occur or objects aren't correctly ordered, thus resulting in a executable that crashes (if the linker actually manages to complete). Manually adding the full library path (/mypath/libone.a) to the dmd command line fixes this problem, if it's included directly after the project object . This may be an issue unrelated to windows library linking problems, however.

Only other thing I can think of is incorrect parameter sizes perhaps in the function declarations. But that doesn't seem to be the case here.

I hope this problem gets resolved.

-JJR

[JJR]

Mike,

I'll see if I can reproduce the problem next chance I get. Maybe you're the only one having the problem.

-JJR

[clayasaurus]

are you still having these problems? i havn't run into anything of the sort on my linux box.

[aldacron]

I've been doing a lot of work in C lately and hadn't touched this in a few weeks. But just took a look at it with the new DMD 0.138 and, yeah, the problem persists. I really ought to try and figure this out.