[CMake] Handle lib64 library on Linux
Sara Rolfe
smrolfe at u.washington.edu
Wed May 25 16:27:30 EDT 2011
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>
More information about the CMake
mailing list