[osg-users] osgQt versioning problem

Jannik Heller scrawl at baseoftrash.de
Thu Jun 11 16:00:22 PDT 2015

Hi Jan,

> The only way you could have problems is if you rely on the OSG 
> libraries shipped by the distro, where you don't have control over how 
> it was compiled. 

That is precisely what's going to happen. My application is likely to become available in distro repositories (FWIW, an older version of my application that isn't using the OSG *is* already in distro repositories). Packaging guidelines typically require a package to use the established library stack. A package isn't likely to get accepted if it ships its own forks of already packaged software. That would be a maintenance and security nightmare.

> I don't think that is necessary - you need to ensure in your
> application that it is built against the correct version of Qt which
> is the *same as the version you use for osgQt*.

Sounds easy in principle, but will cause a waterfall of problems for package repositories.

- Not all application developers are willing or able to upgrade to Qt5 yet.
- *if* there is a mismatch, we just get a crash, instead of the mismatch being detected at the build system stage. The packager or tester is left to dig into the crash to find out what's wrong. There is no way for the application to detect what version of Qt the osgQt was built with, so the application can't provide a sensible error message either. Ultimately, the developer will be left to deal with lots of support requests by frustrated users.
- If one package requires osgQt5, but a different one requires osgQt4, we get a conflict. The user wouldn't be able to install those two packages at the same time. 

Yes, these aren't problems if you ship your application with static libs, but not everyone can or wants to ship software in this way.

> In addition, if you are trying to distribute a binary-only package

I don't. I just distribute source-code and let others worry about the rest ;)

My suggestion is:

- Provide separate libosgQt4/5 libraries.
- Provide a libosgQt library that points to the default, either 4 or 5, for backwards compatibility.
- Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, allowing applications to opt for a specific version.

For now, I'm going with the workaround of upgrading my application to Qt5. 

Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's thoughts are.


Read this topic online here:

More information about the osg-users mailing list