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.)<br><br>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.<br>
<br>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.<br><br>What version of ITK are you using?<br>Is it built as 64-bit libraries?<br>
<br><br><br><div class="gmail_quote">On Tue, May 24, 2011 at 1:33 PM, Sara Rolfe <span dir="ltr"><<a href="mailto:smrolfe@u.washington.edu">smrolfe@u.washington.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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:<div class="im"><br>
<br>
$ grep -i uuid CMakeCache.txt<br></div>
libuuid:FILEPATH=/usr/lib64/libuuid.so<br>
<br>
<br>
Thanks,<br><font color="#888888">
Sara</font><div class="im"><br>
<br>
<br>
On May 24, 2011, at 10:21 AM, David Cole wrote:<br>
<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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...)<br>
</blockquote>
<br>
</div></div></blockquote></div><br>