-
Notifications
You must be signed in to change notification settings - Fork 669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
virtual-files feature on Owncloud client v2.6.0 with Qt 5.12.1 is missing completely #7027
Comments
It is! Maybe you are using a branding that disable it? |
@ogoffart no i used the daily build for 2.6.0 client , i'm aware that branded-client doesn't have VFS |
Maybe the client can't open any of the vfs plugins. @lazawan Could you give me the first 20 lines of the client log file? It should say "VFS windows plugin is available" and "VFS suffix plugin is available". Also look for "owncloudsync_vfs_*.dll" in your install directory. |
Same here: owncloud-client 2.6.0 daily 20190211 on Linux Mint, Ubuntu 18.04
Is there now a VFS plugin that is needed for Linux? Maybe packagaging needs to adapt for structural changes? |
No. Packaging cannot pick up new additions. I need to locate everything manually. Thanks for the hint, I have to ho searching now.. |
@jnweiger The plugin is called "owncloudsync_vfs_suffix.so" built from "src/libsync/vfs/suffix" and should be installed next to the binary. I imagine linux packaging will not like that latter part. I'll check out what paths EDIT: Primarily it uses dlopen, so next to the other shared libraries should work. If it needs a "lib" prefix, we could adjust that. |
DEB packages have it in the build-log but it neither breaks packages with "unpackaged file error", nor is it auto-included anywhere. That is odd. |
Is there a simple test to see where the plugin is searched at runtime? Next to the other libs, with or without a plugins subdirectory, with or without a lib* prefix -> it does not seem to work. |
It gets loaded, if placed next to the binaries in
Alternatively I can place it in $QTDIR/plugins/, which is also somewhat wrong, as it belongs to owncloud, not to Qt. @ckamm that is a mess. We should try to make it work from the libs/plugins folder where libowncloudsync and friends are. I tried setting CMAKE_PLUGIN_INSTALL_DIR, but it has no effect, except that cmake complains this variable is ignored. |
Workaround committed to OBS. Symlink into bin. |
Huh, dlopen() should be using the normal search path for shared libraries, so it should be found among the other libraries that the executable's RPATH points to. I'll install it and check it out, the LD_DEBUG environment variable should be helpful. |
Qt manually resolves plugin paths and uses dlopen only with absolute filenames. I agree that our plugin doesn't belong into the Qt/plugins directory and assume distribution packagers would also be unhappy putting them there. I propose we add a build setting for a path that we add to Qt's plugin search path on startup and then place our plugins there. |
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
By default, plugins are only searched next to the binary or next to the other Qt plugins. This optional build variable allows another path to be configured. The idea is that on linux the oC packaging probably wants the binary in something like /opt/owncloud/bin and the plugins in /opt/owncloud/lib/plugins. Similarly, distribution packagers probably don't want the plugins next to the binary or next to the other Qt plugins. This flag allows them to configure another path that the executable will look in.
@jnweiger Now that this is in the workaround should not be necessary any more. Either set the new PLUGINDIR path, or install to the place it points to by default. Btw, I tested http://download.opensuse.org/repositories/isv:/ownCloud:/desktop:/daily:/master/Ubuntu_18.04/ and didn't get the plugin installed (with the symlink workaround). |
Linux builds seem to install the vfs_suffix plugin now into
Examples:
I am changing the *.install, *.rules *.spec files to pick it up from there. |
tested 2.6.0daily20190322 on ubuntu-18.04 using Qt-5.12.2The plugin is there and works. |
simply VFS is not there :-`( " i mean on all linux Platforms )
regards,
The text was updated successfully, but these errors were encountered: