Description of problem:
Line 21 of the CMakeLists.txt for assimp causes some symbols to be hidden. This behaviour was introduced at svn revision 1069 of assimp (see https://assimp.svn.sourceforge.net/svnroot/assimp/trunk/CMakeLists.txt?p=1069), however the assimp.pc does not reflect the version change until svn revision 1255 (see https://assimp.svn.sourceforge.net/svnroot/assimp/trunk/CMakeLists.txt?p=1255).
Therefore, we are stuck in limbo, where we are unable to detect (in dependant projects) if the symbols are hidden in assimp or not.
Also, the SVN revision indicated by the SPEC file is 1071, while the "patch" version number indicated is 863. I'm not sure, but I believe that assimp uses svn revision as the "patch" version, so the version number of the currently deployed release may be behind.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. View the assimp.pc
2. View the CMakeLists.txt
3. View the assimp.spec
assimp.pc does not reflect version change (reports 2.0 instead of 2.0.1071)
Version change is reflected in assimp.pc and therefore dependant projects know that the symbols are hidden in this version of assimp.
The solution is simply to upgrade to 1255 of assimp or to patch the CMakeLists.txt file to update the assimp.pc file to reflect the "patch" version so this change may be detected.
So if memory serves me correctly, assimp 2.0.853 was the last "released" version of the assimp 2.0 series, downloadable on their sourceforge project page. However, 1071 was the first SVN revision where they split their models between free and nonfree, which allowed me to delete the non-free models and submit the package to Fedora. This is why the SVN snapshot is packaged instead of the last released -863 version.
SVN revision 1255 is quite different from rev 1071 that is packaged, and is really much closer to assimp 3.0 (which is svn revision 1270) than assimp 2.0. Indeed, it looks like most of the patches do not apply cleanly to svn revision 1255, so it will take some time if I go that route. For this reason, I think I would prefer just setting the patch version of the current package to 1071 in CMakeLists.txt for f19 and lower, and rebuilding. Is this satisfactory, or would you rather see the package upgraded?
That will solve my issue, thank you! By the way, I discovered this while compiling ROS Groovy for F19 - AFAIK, it is the only problem in the entire process. Thanks for your help here, I'll submit a patch to ROS to fix their end of this issue as well!
Alright I'll go ahead and update the patch version in CMakeLists.txt. We're about halfway through getting the fuerte base packages into Fedora, and hope to get to groovy in to f20, so this should definitely help.
assimp-2.0.863-10.20110824svn.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing assimp-2.0.863-10.20110824svn.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
assimp-2.0.863-10.20110824svn.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.