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 <[email protected]>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
