On Sunday 08 September 2013 14:19:02 Pali Rohár wrote: > 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/730bc064a070e886e10 > > 95 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_pla > > tfo > > 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?
Now I found this qt function: QStringList QCoreApplication::libraryPaths () http://doc.qt.digia.com/4.7/qcoreapplication.html#libraryPaths "Returns a list of paths that the application will search when dynamically loading libraries." It is used for searching file in QLibrary (but not QPluginLoader). Also used for loading Qt high-level plugin (like style). And this libraryPaths() includes also by default: "The directory of the application executable is always added" So why we should prevent using trojita plugins from location where are loaded qt plugins? And what about using *only* QCoreApplication::libraryPaths() for searching trojita plugins? -- Pali Rohár [email protected]
signature.asc
Description: This is a digitally signed message part.
