Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Allowing Plugin Interdependency and Improving Plugin Management
dmoore:
--- Quote from: oBFusCATed on November 11, 2013, 07:25:15 pm ---The visibility flag is something unrelated to this problem. What it will do is to change the defaults to be a bit more sane, aka windows like. This is something that will happen in the future, when I find the time to do it.
--- End quote ---
Maybe this makes my first patch mostly redundant. If using visibility radically improves link time then it doesn't really matter that all libs get loaded.
--- Quote ---dmoore: I've never tried to place two plugins in a single binary, but I've thought it is supported... but I might be wrong.
--- End quote ---
I think it "kinda" works, but I am not sure about how the manifest naming works and I'm pretty sure that export and uninstall won't do the right thing (i.e. export or uninstall everything in the same dll/so)
oBFusCATed:
--- Quote from: dmoore on November 12, 2013, 04:38:00 pm ---Maybe this makes my first patch mostly redundant. If using visibility radically improves link time then it doesn't really matter that all libs get loaded.
--- End quote ---
I don't think it is related to the load time. The only benefit might be smaller size plugins and of course no more symbol collisions (not really serious problem in c::b).
dmoore:
--- Quote from: oBFusCATed on November 11, 2013, 07:25:15 pm ---
--- Quote from: thomas on November 11, 2013, 06:56:25 pm ---As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too :P). Are you sure it's problematic? I think it might just work fine.
--- End quote ---
dmoore's problem is that he doesn't want to place his so/dll file next to libcodeblocks.so/dll, but this is a requirement at the moment (I've not checked if this is really the case, but I suppose it is).
--- End quote ---
Strictly speaking, the so/dll can be placed anywhere that's in the loader's search path. On windows we can change this path at run time, so no big deal. On Linux, -rpath/-rpath-link adds some flexibility, but it means we can never have plugins that are depended on in users home (becasue we don't know where home is at compile time). Maybe that's a limitation we can live with?
Alpha:
--- Quote from: dmoore on November 12, 2013, 05:20:48 pm ---On Linux, -rpath/-rpath-link adds some flexibility, but it means we can never have plugins that are depended on in users home (becasue we don't know where home is at compile time). Maybe that's a limitation we can live with?
--- End quote ---
I found the following here. It is not elegant, but it might work if needed.
--- Quote ---On UNIXish sytem there is a notion of TMPDIR - if needed, you can first find all the needed libraries, then symlink them to a directory under TMPDIR, then use the the full path with that directory.
--- End quote ---
oBFusCATed:
--- Quote from: Alpha on November 12, 2013, 05:36:51 pm ---I found the following here. It is not elegant, but it might work if needed.
--- End quote ---
Hm, are you really proposing this solution? :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version