OME Files 0.6.0 on Windows 10

Hi!

I’m working on a C++ library that links to the ome-files library. Building the 0.6.0 version ome-files library and linking to it on a Linux or Mac machine was quite straight forward, however, I’ve been struggling to achieve this on a Windows 10 machine for the last few days.

I’m using MS Visual Studio 15 2017 Community Edition, 64bit, so using one of the provided pre-built super builds is not an option.

My question: Has anyone achieved this before (either building ome-files using MSVS 2017 64bit or even linking to it) and can share how it worked out?
Judging from https://trello.com/c/ZcLP9Mg8/5-building-with-c-on-windows this can indeed be quite challenging. The fix from https://www.openmicroscopy.org/community/viewtopic.php?f=13&t=8233 has not helped me…

When building ome-xml, I get the following error message:
Creating library C:/ome-files/build/ome-model/ome-xml/src/main/cpp/ome/xml/Debug/ome-xmld.lib and object C:/ome-files/build/ome-model/ome-xml/src/main/cpp/ome/xml/Debug/ome-xmld.exp OMEEntityResolver.obj : error LNK2001: unresolved external symbol "public: static class std::mutex ome::common::xml::Platform::mutex" (?mutex@Platform@xml@common@ome@@2V0std@@A) [C:\ome-files\build\ome-model\ome-xml\src\main\cpp\ome\xml\ome-xml.vcxproj] OriginalMetadataAnnotation.obj : error LNK2001: unresolved external symbol "public: static class std::mutex ome::common::xml::Platform::mutex" (?mutex@Platform@xml@common@ome@@2V0std@@A) [C:\ome-files\build\ome-model\ome-xml\src\main\cpp\ome\xml\ome-xml.vcxproj] OMEXMLMetadata.obj : error LNK2001: unresolved external symbol "public: static class std::mutex ome::common::xml::Platform::mutex" (?mutex@Platform@xml@common@ome@@2V0std@@A) [C:\ome-files\build\ome-model\ome-xml\src\main\cpp\ome\xml\ome-xml.vcxproj] C:\ome-files\build\ome-model\ome-xml\src\main\cpp\ome\xml\Debug\ome-xmld.dll : fatal error LNK1120: 1 unresolved externals [C:\ome-files\build\ome-model\ome-xml\src\main\cpp\ome\xml\ome-xml.vcxproj]

Any help would be appreciated!

Cheers.

I figured it out myself.
Amongst many other things that need to be changed, using xerces-c as XML DOM is somehow corrupted. With the cmake flag -Dxmldom=qt5 this issue can be avoided.
Also, it’s a good idea to install the required packages using vcpkg and then flagging the toolchain. This will save you a lot of trouble.
Also, for some reason, the file ome-files/lib/ome/files/tiff/Util.cpp is missing #include <cassert>.

Hi @luco,

Have you filed an issue or PR against the Gitlab repo for ome-files 0.6.0 at https://gitlab.com/codelibre/ome/ome-files ?
@Roger_Leigh, who made the 0.6.0 release to support the new BioFormats 6 features and to make the library more independent and robust, is very responsive and will hopefully integrate your fixes quickly.

I’m glad to see this library is being actively used. My company supported the 0.6.0 development and we are also relying on it for our own developments.

Cheers,
Damir

2 Likes

Hi @dsudar,

Thanks for the suggestion, I will reach out and file an issue. I’m more than happy to contribute.

Cheers,
Lukas

Using Qt instead of Xerces and Xalan has its downside in not being able to READ older versions of ome xml schema.

Hi @luco. This issue was already addressed in merge request !147. We will need to make some new releases to incorporate the latest bug fixes for new compilers.

This is entirely correct @DanM. The XSLT transforms are a bit of a pain point. Unfortunately, for the transforms we have to deal with, Xerces+Xalan are the only two libraries capable of processing them. I did try with QtXmlPatterns, but it’s XSLT 2.0 only, and the older transforms don’t work; we would have to rewrite them. And I’m afraid to say, I don’t understand all their subtleties, since they aren’t all well documented, and I don’t have a comprehensive set of reference files to test them against. The OME project does have some older schema version samples, but they are far from comprehensive, and I would like to avoid risking breakage.

Ideally, I would like to eliminate the XSLT transforms entirely in favour of something more portable and maintainable (and understandable). Some possibilities:

  • We require Qt5, drop all Boost/Xerces/Xalan dependencies. We could rewrite the transforms to use XSLT2.0 as provided by Qt5 QtXmlPatterns. Rewriting the transforms is risky.
  • We implement our own manual DOM transformation and do the upgrade “by hand” using the XML DOM. Has the advantage of working with both Xerces and Qt XML DOM APIs, but would be rather manual.
  • We use SQLite as an internal database representation of the OME data model, and use a SAX parser to import all schema versions, then manually upgrade using SQL schema updates. I’m interested in exploring this for performance and memory reasons; the existing DOM+model object representation does not scale well either in OME Files or Bio-Formats. We could use in memory or on-disc database files.

I’m afraid I don’t currently have the time to do such large undertakings though. But I would be interested in hearing everyone’s thoughts on future directions. If I can’t do it, someone else might want to, and I can certainly do smaller pieces of work and get us there incrementally.

In terms of supporting the wider community, we historically tried to avoid any hard dependency upon Qt, so that you could use the standard library only (with Boost as a fallback where that wasn’t possible). We’re pretty close with C++17 to dropping every single Boost header. That said, Qt offers a lot of value, and unlike the standard library, the Qt abstractions lend themselves to use in DLL interfaces. We could do a better job of providing OME Files DLLs (on Windows) if the API and ABI didn’t use std:: string and container types. While I don’t have a strong preference either way, supporting all the different combinations is difficult and time-consuming, and so requiring Qt and using its abstractions would be one option to consider. But that might not be something all end users would be happy with.

Kind regards,
Roger

Maybe also worth keeping an eye on XSLT 3, they seem to have streaming in mind.

(post withdrawn by author, will be automatically deleted in 72 hours unless flagged)