[CMake] Handle lib64 library on Linux

[David Cole]

I think re-asking this question over on the Insight Users list would be
appropriate. There's a much wider audience of Insight users (people building
applications just like this) on that list.

I'm sure there are people who have built 64-bit Linux programs using ITK and
VTK over there. There must be an answer to this question from someone.

HTH,
David


On Tue, May 24, 2011 at 2:56 PM, Sara Rolfe <smrolfe at u.washington.edu>wrote:

> 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 <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/47d0be3d/attachment.htm>