Linker Error: Symbol Undefined with opAssign
Closed this issue · 5 comments
Edit: Sorry if this is an incorrect vector for asking for help with issues like this. I'm new to github, and I was unable to find any contact information to speak to the developer(s) directly. I was at a loss where else to ask about this.
Hello. I've been trying to get LuaD up and running in my personal engine. Things have been going fairly well (I had to update my D compiler, at one point), but I'm running into a linker error that I can't figure out.
I'm getting the following error message:
"Error 42: Symbol Undefined _D4luad4base9LuaObject8opAssignMFNbNcNeS4luad4base9LuaObjectZS4luad4base9LuaObject (nothrow ref @trusted luad.base.LuaObject luad.base.LuaObject.opAssign(luad.base.LuaObject))"
I believe the issue has something to do with the fact that I'm compiling my engine into a library, and then linking that library in another project. The library project compiles just fine, but it's the second project which includes it that displays this error. I've linked luad-lib (or luad-d.lib) and lua51.lib in both projects.
I'm not entirely sure where the issue lies. Is it an issue with LuaD? Is it an issue with the D compiler? Or is it an issue with my inability to set things up correctly? I've been picking away at the problem through Google for a few days now, but after getting no where, I decided it would be best to start asking questions at the source.
It's definitely not a LuaD bug, unfortunately. However, there might be a way to work around it.
Handling of object code emission was changed in DMD 2.064 and a lot of people have experienced linker errors because of that. The changes are supposed to only relate to template instantiated code, but to get the old behaviour you can use the -allinst switch, have you tried that?
For the record, luad.base.LuaObject.opAssign is a compiler-generated function. Maybe that makes it more prone to having bugged code generation. Have you searched the D bug tracker? Implementing an explicit opAssign might help, too.
Sorry about the breaking changes due to switching to a newer compiler release, I've been doing that quite aggressively... I am planning on starting versioning soon, there are just a few things I want to finish first.
I hadn't tried the -allinst switch, but including it in either project or my build of LuaD didn't seem to help (or harm as far as I can tell). I recompiled LuaD - I had forgotten to do this after upgrading compilers - and I think this was the cause of my problem. (You jogged my thought process about that!)
As always seems to happen, this fixed my previous error, but I now have a new one. I'm now getting "Error 162: Bad Type Index reference to type 84A9" errors. This ONLY happens in Debug mode, interestingly. For now, I can at least play around in Release mode until I can find a solution for it. I'll poke around the D bug tracker as well =) If you happen to immediately recognize the error and what might be causing it though, let me know.
And I appreciate your help! I've found LuaD (like so much with D) unbelievably easy and clean to use. I've worked with LuaBind in C++ quite a lot, and I haven't run into anything near the headaches I had in both setting LuaBind up, as well as using it.
And I appreciate your help! I've found LuaD (like so much with D) unbelievably easy and clean to use. I've worked with LuaBind in C++ quite a lot, and I haven't run into anything near the headaches I had in both setting LuaBind up, as well as using it.
I can't find the words to say how happy I am about finding D. I was out of my mind this and that where you can or can't use templates in qt's signals & slots but you get 25 pages of errors when you can but can't, and you're never done debugging multi-threading. ever.... C++ is truly the worst clusterfuck now and D fixes it all, and if it didn't -- I can assure you it's well on its way to and gracefully too.
I'm now getting "Error 162: Bad Type Index reference to type 84A9" errors.
I found a similar error when searching "Bad Type Index reference to type" on google, "which boiled down to the linker not liking the type information written for "enum DayOfWeek : ubyte". Using int as the base type fixed it"
I ran into a problem trying to debug it with symbols turned on in visual-d, I fixed this by changing luad/c/lua.d from const LUA_TSTRING = 4; to const LUA_TSTRING = cast(size_t)4; maybe it's related? You could try disabling debug symbols or replacing the line there.
You may also have another outdated library (compiled with an older dmd version)
Thanks for the suggestions etcimon! Turning symbols off fixed it! (Properties->Compiler->Debug, Debug Info set to None.) What exactly am I losing in debugging information/utility, if anything, with symbols turned off? Unfortunately, the other trick (hack?) didn't do me any good, for anyone who might find this discussion.
I agree about D. C++ was my first language, and I understand why it's been industry standard for so many projects; C++11 even adds quite a few features that are excellent (variadic templates!). That said, I feel C++ was very correctly named: It's C with lots of extra features. Where as D really does feel like a true OO upgrade from C.
Edit: That said, I'm unsure how I'll feel about D's GC. From what I've read and understand, D at least does it well; but, I'm speaking from the perspective of a game developer who cares a lot more about how memory is managed (and in general, wants direct control over every frame).
Update: This issue has been solved, so I'm going to close it now =) Thanks for your help everyone, and thanks for LuaD! I'm still learning what I can and can't do (const function parameters are a no-no, unless I'm just doing them wrong), but I'm able to pass around fairly arbitrary classes and access their members pretty seamlessly now =) Even singletons work fine - I was pleased to see this! D Magic at its best.
That said, I'm unsure how I'll feel about D's GC.
There are quite a bit of containers and allocators available that go around the GC. Malloc FreeLists are available in vibe.d here https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/memory.d
and there's HashMap, Dictionary & Array there too. I suggest you implement everything in FreeLists though, it'll speed up things vs C's malloc rather than slow down because of the GC! ;)
Personally I like to keep stuff in malloc containers /w freelists and then move things I immediately need in the GC with .dup instead of wrapping it in a RefCounted struct (which is a little like shared pointers). So much more simple, a perfect hybrid!