search

itfrombit / osx_handmade

OS X port of Handmade Hero
155 stars 18 forks source link

Question on dylib handling #2

Closed joekarl closed 9 years ago

joekarl commented 9 years ago

Did you ever get your dylib code to successfully reload your dylib? I have it loading up just fine in my port, but can't seem to get it to reload. It actually runs through the reload code just fine, but always gets the same version of the dylib (despite manually checking that the dylib file is the new version). Basically the behavior is it seems like the original dylib is being loaded but never unloaded.

I did some investigation, and apparently the objc runtime doesn't allow dylibs to be unloaded (at least according to http://stackoverflow.com/questions/8793099/unload-dynamic-library-needs-two-dlclose-calls). I didn't know if that jived with what you'd seen or not...

joekarl commented 9 years ago

Hmm... well maybe not, I don't actually know what is going on... here, all I know is the dylib never seems to be unloaded.

joekarl commented 9 years ago

For reference, my loading code is here, https://github.com/joekarl/swift_handmade_hero/blob/master/Handmade%20Hero%20Swift%20Platform/Handmade%20Hero%20Swift%20Platform/GameCodeLoader.swift

Essentially just doing a dlopen, grabbing the funcPtrs out. Then on reload, doing a dlclose then running through the load code again.

joekarl commented 9 years ago

Ah, ok figured it out. I was being dumb and linking the dylib in my platform layer. Because it was linked, the dylib once loaded could never be unloaded because it was cached in the runtime and not allowed to be unloaded once loaded. By not linking directly to the dylib (and only including the handmade_platform header directly) the dylib can be unloaded. Freaking sweet.

itfrombit commented 9 years ago

Glad you figured it out. I think the Stack Overflow article you mentioned is talking about not being able to unload Cocoa objects once they are loaded via a dylib, probably because there may be instances of the classes (or subclasses) that have already been created in the runtime. But that shouldn't apply to what we're doing here with non-objective-C constructs such as simple C functions.