[osg-users] Build Error on Windows

Mark Sciabica msciabica at itracs.com
Tue Mar 24 15:50:05 PDT 2009

Robert Osfield wrote:
> This exception covers the distribution of your final application, not 
> source code modifications.  If you modify the source then those 
> modifications must be open sourced under the same licence as the 
> orignal work - the LGPL parts of the license cover this.
The exception refers to "works based on the Library". The phrase "based 
on" is defined in the GPL and covers any source code changes. If this is 
not what you intended I would recommend changing the license.

Again, I don't expect that my company will be behaving contrary to your 
current understanding of the license, but it seems that some behavior is 
allowed by the license that you want restricted. You might want to check 
this with a lawyer.
>     Where do I configure the SO version number, and how does it
>     restrict which plugins are loaded?
> The plugins directory is number be the version.  If you bump the SO 
> version then there will always be bump of the version number.
So I would use version 2.8.1 then? Seems this would easily conflict with 
someone else's updates. Or an official patch to OSG. The SO version 
doesn't seem to affect plugins.
>     I don't think this addresses the general problem handling the
>     coexistence of builds using different compiler versions or build
>     options (e.g. different settings for OSG_USE_FLOAT_MATRIX). Should
>     everyone use a different SO version number? Should we just accept
>     that multiple installs of OSG may not work on a single machine?
> If you have multiple installs then you shouldn't have a problem.  But 
> if you say you are installing it one place and then move it elsewhere 
> and don't set the paths explicitly and have version number and SO 
> versions overlapping then you may come across a problem.
I install it in a path configured by the user when he installs the 
application. This is pretty much standard behavior for programs 
nowadays. The problem is that OSG compiles in an install path at build 
time, which is much too early in the install process (with a possible 
exception for developers).

Let me spell out specifically a sequence of events that will lead to a 

1. Two applications, AppA and AppB, distributed by different companies, 
install the same version of OSG on a system.
2. These two builds of OSG use different options for 
OSG_USE_FLOAT_MATRIX (or some other setting).
3. These two builds use the same (default) compiled in 
4. AppA installs a plugin not installed by AppB.
5. AppB will find this plugin in its plugin search path and try to use 
it if the user tries to load a file of the appropriate type.
6. Any MatrixTransforms created by this plugin will be binary 
incompatible with the running version of OSG. A crash will likely ensue.

The only steps that look reasonable to change to fix this problem is #3 
or #5: where plugins are loaded. Either make sure everyone who 
distributes an OSG binary uses a unique install path or not have the 
install path searched. Your preference seems to be to tell developers to 
move their plugins if their customers have problems. I personally think 
this problem should be avoided before customers get their hands on the 
product. Force developers to specify a unique install path in the CMake 
configuration (if CMake has this ability, perhaps suggesting they use 
their company or application's name in the path), or drop the default 
install path.



More information about the osg-users mailing list