On Samstag, 7. September 2013 10:15:47 CEST, Pali Rohár wrote:
So why adding new code "impl = new" for each plugin, if Qt support Q_IMPORT_PLUGIN which adding plugin into QPluginLoader?
To bypass your apparent linker hazzles? No linker trouble, no hard requirement. It's btw. also what QStyleFactory did and does: http://qt.gitorious.org/qt/qtbase/source/730bc064a070e886e10950ccfd59780e8976f5fd:src/widgets/styles/qstylefactory.cpp
This means that some plugins can be initialized only via "new" and some plugins only via QPluginLoader...
Not "can" but "will" - depending on whether you choose to compile them as dynamic plugins or not.
This will increase plugin manager code, complicate it and make hard to understand.
Seriously, no. We're talking about maybe 2-3 compiled in backends and it's not hard to read that "plugins with the following names are compiled in and instatiated directly"
Because I couldnt have admin rights?
Contact your admin.
Or because I moving my local executable binaries to another place?
Because you want to annoy the packagemanager?
Really, I have more programs in ~/bin/
$ ll ~/bin | wc -l 144 Those are however 98% (little) scripts and some simply C tool with hardly more than a main() implementation.
and every program working fine if is started from any location.
Trjita is just gonna work fine if you move the binary around. That doesn't mean you could just move around the stock Qt plugins or whatever. If you think you need to allow overriding resources for this, there's a spec and it says -> ~/.local/* "." is *never* a good resource resolution (even MS has figured that in the meantime)
At compile time. I'm not able to copy binary to another computer.
Well, no. First: this is simply not how SW is distributed on Linux/BSD (NeXT/GNUStep is entirely different, yes) Second: you of course need to ensure the required libs/resources are present. No QtGui -> linker resolution fails, trojita won't run. Third: If the above is resolved, it's a matter of preserving resource paths. If you put the contents of /usr/share/locale/ into '.' or even /usr/bin and expect to get working localization - you're wrong. This holds for most software - virtually everything that operates on runtime resources. If you want to be able to drag and drop one single file from one computer to another and have it run, regardless of the other system (except that it can load ELF binaries) you need to go for a container installation (NeXT) or compile in all resources (images, icons etc.) and link *everything* statically. That's just the way it is. It's however not considered very sane because you create a very fat binary that eventually doubles much space in RAM.
I need to compile it also on that computer with different (system) plugin path.
No? You can utilize the same path or define the plugin dir to be actually "." when your compilation targets eg. NeXT/GNUStep alike setups (where "portable" was borrowed from in the first place) You'll then have a trojita version that runs in an appdir. Fine. It's just really not what unix/linux distros usually would do.
Really why is problem first trying to load plugins from executable directory?
It's a DOS/Win3.11/ disease? http://brianreiter.org/2010/08/26/microsoft-should-formally-deprecate-cwd-from-loadlibrary-search/ http://technet.microsoft.com/en-us/security/advisory/2269637 http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=DLL+Hijacking&filter_author=&filter_platform=0&filter_type=0&filter_port=&filter_osvdb=&filter_cve= It's not an absolute security risc, since instead of injecting a DLL I could move a compromised binary in your $PATH, but it weakens the system for sure.
And portable versions?
"Usecase is windows" - and you can actually be sure that "running random stuff from somewere" is what MS is gonna downforce with Win9 or 10. For Linux, just bring your live distro. Better for you, better for the system you want to use. However, if you want to compile for such distribution, choosing the resource paths at runtime will allow you to do so. (You likely got to care about more, though - eg. config file resolution) Thomas
