[CMake] Handle lib64 library on Linux

Sara Rolfe smrolfe at u.washington.edu
Tue May 24 14:50:27 EDT 2011


I'm using InsightToolkit-3.14.0.  I've used this installation from  
another 64-bit machine successfully, so I had assumed it was ok.  I  
didn't build it myself so I'm not sure.  Do you know how I can check  
this?

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  
> <smrolfe at 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...)
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110524/75cc9682/attachment-0001.htm>


More information about the CMake mailing list