is not a valid Qt plugin error on startup
#30
Comments
naucoin
pushed a commit
to naucoin/SlicerOpenCV
that referenced
this issue
May 5, 2016
When SlicerOpenCV is packaged and installed, Slicer is showing various errors related to the extension's Logic module. Most seem to be related to VTK errors. Adding the VTK libraries to the list of target libraries explicitly, following the example of the Chest Imaging Platform AirwayInspector extension that was checked to work, this change results in a properly loaded extension from the package file. Issue Slicer#30
|
xref SBU-BMI/SlicerPathology#39 @naucoin Good catch I wonder what was the output of |
|
Also strange it is mentioned |
|
Hmm, with today's nightly, I get more errors, although they are different |
|
Ah, nevermind - it picked path settings from my local build, will fix and update soon. |
|
After removing paths to the locally built extension, I am getting the same errors as yesterday: @jcfr the output of |
|
Looking at the results of otools on my machine (nightly build + extension manager install of SlicerOpenCV), and checking for those files, I get: Looking for those files: So the module logic is in the wrong place, and the ITK Video Bridge didn't get installed at all. |
|
In my local build of SlicerOpenCV, the ITK library is there: |
|
Good catch! |
|
@naucoin Great. Thanks for the report. Very helpful. I will work on a fix to address this. |
|
More oddness: in the .tar.gz that I produce locally I have two copies of the logic library: |
|
@jcfr thanks! |
Most likely a side effect of the fixup. Until now, the assumption was that all Slicer libraries were properly fixed when creating extension packages. To avoid recursing through all dependencies of Slicer when fixing up an extension ... each time the result returned by otool matches a library living under the Slicer build tree .. we skip it. This is why we have a custom fixup module for extension different from the one used to fixup Slicer: SlicerExtensionCPackBundleFixup.cmake.in vs SlicerCPackBundleFixup.cmake.in |
|
Locally building the package, we get: A first problem is that the installation of |
|
It turns out that setting Since the fixup code is associated with the current project, it will be executed first. See here for the source. |
|
An approach to explore would be to run the fixup code as the last "project". That should be possible without too much work because the fixup is already moved into his own directory. See here |
jcfr
added a commit
to jcfr/SlicerOpenCV
that referenced
this issue
May 11, 2016
This commit copy the common Slicer script from "Slicer/CMake/SlicerExtensionCPack.cmake" to "SlicerOpenCV/CMake/SlicerOpenCVExtensionCPack.cmake". Modification specific to SlicerOpenCV are indicated by comment "# SlicerOpenCV" Ultimately, the updates should be contributed back to Slicer core.
|
Now that the fixup happen last, here is the output: We can see the following issues:
|
|
error |
jcfr
added a commit
to jcfr/SlicerOpenCV
that referenced
this issue
May 11, 2016
|
Now the |
|
There is still remaining libraries in Ensuring that
Note: For now the
|
|
I plan on addressing this before the end of the week. |
|
Look like I have all the pieced together to fix packaging on MacOSX 😄 Will update Slicer and submit a PR after lunch. |
|
sounds promising! 👍 |
jcfr
added a commit
to Slicer/SlicerGitSVNArchive
that referenced
this issue
Jun 10, 2016
Having the ids of library set as full path is mandatory to ensure fixup bundle script works properly. Setting CMAKE_MACOSX_RPATH to 0 ensures that @rpath will not be automatically be applied to extension module libraries where the CMake minimum required version >= 3.0. CMake 3.0 is the version where CMP0042 is set to NEW by default. CMP0042 set to NEW means that CMAKE_MACOSX_RPATH is ON by default. Notes: Existing workarounds within Slicer core (e.g use of patched version of ITK forcing CMP0042 to OLD) will be removed and a similar change will also be applied to SlicerCPack.cmake. See Slicer/SlicerOpenCV#30 git-svn-id: http://svn.slicer.org/Slicer4/trunk@25180 3bd1e089-480b-0410-8dfb-8563597acbee
jcfr
added a commit
to Slicer/SlicerGitSVNArchive
that referenced
this issue
Jun 10, 2016
…ens last For extension of type "SuperBuild", the external projects to install are specified by appending build directories to the variable "CPACK_INSTALL_CMAKE_PROJECTS", then this variable is processed at packaging time by "CPack". This means that simply ensuring the fixup script is executed last during the install of the current project was not sufficient. Instead, this commit creates a minimal CMake project named "<ExtensionName>-Fixup" that is including the fixup script. Then, this project is appending last to the variable "CPACK_INSTALL_CMAKE_PROJECTS". See Slicer/SlicerOpenCV#30 git-svn-id: http://svn.slicer.org/Slicer4/trunk@25181 3bd1e089-480b-0410-8dfb-8563597acbee
jcfr
added a commit
to Slicer/SlicerGitSVNArchive
that referenced
this issue
Jun 10, 2016
…libs Introduces "Slicer_THIRDPARTY_(BIN|LIB|SHARE)_DIR" and "Slicer_INSTALL_THIRDPARTY_(BIN|LIB|SHARE)_DIR" variables providing a well defined interface for configuring the build and install directories of external projects. This commit also updates the extension fixup script to consider libraries associated with thirdparty libraries. See Slicer/SlicerOpenCV#30 git-svn-id: http://svn.slicer.org/Slicer4/trunk@25182 3bd1e089-480b-0410-8dfb-8563597acbee
|
Using the latest Slicer, this PR should address the macosx packaging problems. See #34 If that works for you I will squash the commit. |
jcfr
added a commit
to jcfr/SlicerOpenCV
that referenced
this issue
Jun 11, 2016
* Required Slicer >= r25182, this will ensure fixup of MacOSX libraries happen last. * To ensure fixup script works as expected, build ITKVideoBridgeOpenCV libraries outside of ITK build tree and install them in the extension package.
|
@jcfr @fedorov Success! LGTM for merging. For the record: I just did a rebuild, not from scratch, after updating Slicer. Then I did a clean build of the opencv extension module, then make package, then install from file in the Slicer Extension Manager (it's not seeing any extensions at all right now). Restarted, no errors, but it does have the debugging print out that I had removed, so JC's branch is behind the trunk. |
Indeed. Let me rebase and re-organized commits.
Let's create a dedicated issue to track this. |
|
@jcfr Thanks! Looks good, integrating now. |
Good to now. Do you have an order of magnitude to quantify the improvement ? As a side note, you could do this to measure: |
|
Nothing concrete, but I started allowing Slicer to load CLIs and it's still much faster than it used to be without them. Running the measurement script: |
|
On Mon, Jun 13, 2016 at 2:18 PM, Nicole Aucoin notifications@github.com
Indeed, thanks to lazy loading, number of CLIs should have no impact (or +1 919 869 8849 |
|
Verified that SlicerOpenCV works fine on Mac now! Thanks for resolving this! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: