On Saturday 07 September 2013 14:11:14 Thomas Lübking wrote: > 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/730bc064a070e886e1095 > 0ccfd59780e8976f5fd:src/widgets/styles/qstylefactory.cpp >
If you want to be sure that executable will have code of static plugin and if not force linker show error, then Q_IMPORT_PLUGIN will work also without problem. So if this is problem which you want to solve with "impl = new plugin", then it is not needed. > > 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" > This means that only selected plugins can be linked into executable. And I want to customize building as possible. > > 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-de > precate-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_platfo > rm=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 Ok, so I see that everybody is against loading plugins from application directory. What about this solution? Load plugins from system path specified at compile time and also from some application subdirectory (plugins). And third posibility so specify custom path via env variable, command line option or config option. This fix problems that plugins will not be loaded from /usr/bin/, but trojita will try /usr/bin/plugins/ (which fail and is faster as listing all files in /usr/bin/), also fix problem if I want to load plugins from /my/very/clever/path (I will specify that env variable or cmdline/config option) and support loading plugins from build directory (in plugins subdir). What I do not want is hardcoding build directory into trojita executable when build service compiling package (rpm, deb, ...). Maybe another (funny) solution for loading plugins from build directory (without installing). Support for loading shared libraries from build directory is already done by cmake via adding build directory to rpath to all ELF binaries. When binaries are installing, cmake removing rpaths. So what about loading plugins from rpaths? It is even possible to read rpath in application? -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
