[CMake] Handle lib64 library on Linux

[Sara Rolfe]

I've made some progress on debugging this issue.  The ITK installation  
I'm using was actually built as 32-bit libraries.  The 64-bit machine  
I used before defaulted to building/running as 32-bits.  Now they're  
being built as 64-bits, which is causing these issues.

Can I specify something in the CMakeLists.txt that will force a 32-bit  
build?


On May 24, 2011, at 12:04 PM, David Cole wrote:

> 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/20110525/ce3cfc58/attachment-0001.htm>