I have also tried InsightToolkit-3.20.0 unsuccessfully.
Thanks,
Sara
On May 24, 2011, at 10:46 AM, David Cole wrote:
I was looking for the source of the issue. (Hoping that whoever was
adding uuid to the list of libraries would be caching a find result.
Apparently they are not.)
Which means that they are referencing this library either simply by
name ("uuid") or by the incorrect full path in the list of libraries
that you are linking with.
If you are only using ITK and VTK, then the culprit is likely the
GDCM third party module within ITK. It is the only thing in the ITK
source tree that references uuid.
What version of ITK are you using?
Is it built as 64-bit libraries?
On Tue, May 24, 2011 at 1:33 PM, Sara Rolfe
<smro...@u.washington.edu> wrote:
Unfortunately, changing the variable name from LIBVAR to uuid does
not fix this issue, so it may be that it is not used as a variable?
I now get:
$ grep -i uuid CMakeCache.txt
libuuid:FILEPATH=/usr/lib64/libuuid.so
Thanks,
Sara
On May 24, 2011, at 10:21 AM, David Cole wrote:
the same variable name as the sub-project that's finding it for
you, you should be able to "preset" that variable before finding the
package that includes it. (Assuming they're using a variable to do
this, and not simply adding "uuid" as a targeted link library...)
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
