Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1057985 - collada_dom-config.cmake calculates incorrect paths
Summary: collada_dom-config.cmake calculates incorrect paths
Alias: None
Product: Fedora
Classification: Fedora
Component: collada-dom
Version: 20
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Till Hofmann
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-01-26 11:03 UTC by Scott K Logan
Modified: 2015-05-26 03:34 UTC (History)
7 users (show)

Fixed In Version: collada-dom-2.4.3-3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-05-22 17:56:11 UTC
Type: Bug

Attachments (Terms of Use)

Description Scott K Logan 2014-01-26 11:03:14 UTC
Description of problem:
cmake reports COLLADA_DOM_INCLUDE_DIRS is //include/collada-dom;//include/collada-dom/1.5 (note the lack of "usr") to projects which depend on collada-dom.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start with a "minimal" installation of Fedora and install collada-dom-devel
2. Create a cmake project which finds collada-dom
3. message() the COLLADA_DOM_INCLUDE_DIRS to screen

Actual results:

Expected results:

Additional info:
Some more debug from collada_dom-config.cmake:

At the beginning, CMAKE_CURRENT_LIST_FILE=/lib64/cmake/collada_dom/collada_dom-config.cmake, which I believe is the root of the problem. I'm not sure if this is actually a bug in collada-dom, but hopefully someone can move it in the right direction.

Comment 1 Scott K Logan 2014-01-26 11:09:43 UTC
I just hit this in PCL's cmake, too. It is not specific to collada-dom at all. I'll try to narrow it down a little bit...

Comment 2 Scott K Logan 2014-01-26 12:08:54 UTC
Looks like I need CMAKE_PREFIX_PATH=/usr in env or else cmake bases everything at / instead of /usr.

This is a fedora minimal install I just did today.

Comment 3 Orion Poplawski 2014-01-27 02:59:20 UTC
              Path used for searching by FIND_XXX(), with appropriate suffixes

              Specifies a path which will be used by the FIND_XXX()  commands.
              It  contains  the  "base"  directories,  the FIND_XXX() commands
              append appropriate subdirectories to the  base  directories.  So
              FIND_PROGRAM() adds /bin to each of the directories in the path,
              FIND_LIBRARY() appends /lib to  each  of  the  directories,  and
              FIND_PATH()  and  FIND_FILE() append /include . By default it is
              empty, it is intended  to  be  set  by  the  project.  See  also
              CMAKE_SYSTEM_PREFIX_PATH,                    CMAKE_INCLUDE_PATH,

Empty default is expected.

Comment 4 Rex Dieter 2014-01-27 05:08:07 UTC
Fwiw, contains this snippet:

get_filename_component(_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_PREFIX "${_PREFIX}" PATH)
get_filename_component(_PREFIX "${_PREFIX}" PATH)
get_filename_component(COLLADA_DOM_ROOT_DIR "${_PREFIX}" PATH)

is what's used to calculate its prefix value.

Comment 5 Scott K Logan 2014-01-27 05:14:52 UTC
I saw that, and as I mentioned, when the config.cmake executes:


so it ends up with _PREFIX=/

which is incorrect. The reason that I deduced that this was a cmake bug was that the script was executed from the wrong location. find_package() found it in /lib64/cmake instead of /usr/lib64/cmake.

If this is intended behaviour in cmake, then that snippet needs to be changed to handle it, but since I hit the same problem in another package, it leads me to believe that this is a cmake issue.

Hopefully the cmake folks are listening and can shed some light on this.

All that I'm saying about the CMAKE_PREFIX_PATH is that it is the only way I can get cmake to find the config.cmake in the CORRECT location, instead of in /lib64/cmake.

Comment 6 Orion Poplawski 2014-01-27 05:32:09 UTC
collada_dom-config.cmake needs to not calculate paths during dependent cmake runs, but rather set them according to where they are being installed at collada-dom build/install time.

Comment 7 Scott K Logan 2014-01-27 06:08:10 UTC
Thanks for clearing this up, Orion. I see now that the snippet is incorrect.

Do you have any idea why the system is finding the config.cmake in this way to begin with? I know it doesn't seem to have anything to do with my $PATH this time around, but beyond that, I can't figure out why this installation of Fedora is doing things differently...

My CMAKE_SYSTEM_PREFIX_PATH=/usr/local;/usr;/;/usr;/usr/local
which seems to be the norm, so that can't be the root cause...

I'd like to know how many packages this quirk affects. The only other one I know for sure is pcl, so I'll loop rmattes in on this bug.

So just to clarify, the repro for this bug is to create a cmake project, and try to find_package() collada_dom (or pcl) with -DCMAKE_PREFIX_PATH=/

Thanks all,


Comment 8 Rex Dieter 2014-01-27 15:16:16 UTC
It's likely getting confused due to

Comment 9 Rex Dieter 2014-01-27 15:18:37 UTC
Looks like one possible fix is to use
REALPATH option of get_filename_component, to resolve symlinks


Comment 10 Rich Mattes 2014-01-27 15:41:38 UTC
Thanks for adding me in Scott, I think that the code that this patch[1] tries to fix is the root of the problem in pcl.  

To fix it, I'm just going to patch it to stop playing games with relative directories and use CMAKE_INSTALL_PREFIX directly as the PCL_ROOT when PCLConfig.cmake is generated.  This should be OK as our pcl is installed system-wide, if someone has a private build of pcl they want to reference they can override the CMake detection paths to discover the local PCLConfig.cmake.  

I thought I had made that change already, but I think the fix is in the pcl-1.7.1 update I'm working on (and will try to assign higher priority to now.)


Comment 11 Rich Mattes 2014-04-06 15:20:05 UTC
PCL is fixed with the updates to 1.7.1

Comment 12 J. Sastre 2014-08-19 13:47:13 UTC
Fedora moved its bin and libs to /usr. If /sbin:/bin is included in the PATH environment variable CMake adds / as a search path. As /usr/lib64 can be reached via /lib64 (not tested on x86 arch) CMake may get confused when trying to determine PREFIX paths (depending on how they are resolved in its <PKG_NAME>Config.cmake) and cause some packages to fail when compiling.

To avoid this behavior remove references to /bin and /sbin from $PATH. After that Cmake should work as expected.

I'm debugging CMake to figure out whether this is really a bug (not sure by now).



Comment 13 J. Sastre 2014-08-20 11:34:37 UTC
Cmake bug filled regarding this (

Comment 14 Fedora Admin XMLRPC Client 2015-04-30 08:10:19 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Scott K Logan 2015-05-12 20:37:40 UTC
This is still a problem in Fedora 21. Any chance someone can take a look?

Comment 16 Fedora Update System 2015-05-13 14:43:49 UTC
collada-dom-2.4.3-6.fc22 has been submitted as an update for Fedora 22.

Comment 17 Fedora Update System 2015-05-13 15:06:21 UTC
collada-dom-2.4.3-5.fc21 has been submitted as an update for Fedora 21.

Comment 18 Till Hofmann 2015-05-13 15:17:04 UTC
Thanks to everyone who has been helping with this. I've submitted a fix where the path is explicitly substituted at build time, and I've also sent the patch upstream [1].

Could you test if the submitted update indeed fixes the issue?


Comment 19 Fedora Update System 2015-05-13 15:27:39 UTC
collada-dom-2.4.3-3.fc20 has been submitted as an update for Fedora 20.

Comment 20 Fedora Update System 2015-05-14 11:12:10 UTC
Package collada-dom-2.4.3-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing collada-dom-2.4.3-3.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 21 Fedora Update System 2015-05-22 17:56:11 UTC
collada-dom-2.4.3-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2015-05-22 17:58:15 UTC
collada-dom-2.4.3-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2015-05-26 03:34:03 UTC
collada-dom-2.4.3-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.