The Find.CUDA module returns 32bit libs on a 64bit platform, is this a bug
or what?
For example, in OpenMM, it returns:
/usr/local/cuda/lib/libcublas.so
/usr/local/cuda/lib/libcufft.so
On an Ubuntu 10.04 amd64 platform with a 64bit install of the nVidia driver
and software, i.e.:
$ ls /usr/loca
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
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 mea
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
I guess that's fair; but what appears to be happening is that it's
deleting the cache even if the -D compiler string is the same as
what's already in Cache.
On Mon, May 23, 2011 at 4:45 PM, David Cole wrote:
> On Mon, May 23, 2011 at 5:37 PM, kent williams
> wrote:
>>
>> Ran into this with CMak
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 librarie
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 v
Hi David,
I get:
$ grep -i uuid CMakeCache.txt
LIBVAR:FILEPATH=/usr/lib64/libuuid.so
Sorry for the double email, I dropped the mailing list in the last one.
Thanks, Sara
On May 24, 2011, at 10:21 AM, David Cole wrote:
On Tue, May 24, 2011 at 12:54 PM, Sara Rolfe
wrote:
Update: I've attemp
On Tue, May 24, 2011 at 12:54 PM, Sara Rolfe wrote:
> Update: I've attempted to add /usr/lib64/libuuid.so as an external library,
> but am still getting the same error. When I run ccmake it appears to find
> the location of the library. Below is my CMakeLists.txt in case I have made
> any errors
Update: I've attempted to add /usr/lib64/libuuid.so as an external
library, but am still getting the same error. When I run ccmake it
appears to find the location of the library. Below is my
CMakeLists.txt in case I have made any errors here:
cmake_minimum_required(VERSION 2.6)
PROJECT(G
Is there some other way that I can force CMake to find /usr/lib/
libuuid.so? Like if I included it as an external library?
Thanks,
Sara
On May 23, 2011, at 2:29 PM, Sara Rolfe wrote:
Hi Eric,
Yes, I believe it is a dependancy from ITK. I saw that wiki page
and at the time did not have t
On 05/23/2011 01:39 PM, Marcel Loose wrote:
> On Mon, 2011-05-23 at 07:21 -0400, David Cole wrote:
>> On Mon, May 23, 2011 at 4:13 AM, Marcel Loose wrote:
>> Hi all,
>>
>> A colleague of mine reported a bug in our CMake-base build
>> system when
>> doing a
I just realized that the second solution has one flaw.
You will need to reset the guard variable in the root CMakeLists.txt file via
set (CUSTOM_COMMANDS_INCLUDED 0 CACHE INTERNAL "" FORCE)
--Andreas
On May 24, 2011, at 10:37 AM, Andreas Schuh wrote:
> Hi Theodore,
>
> Your observation is int
Hi Theodore,
Your observation is interesting, I had expected CMake to not remember function
definitions across subtrees similar to non-cached variables. Apparently, it
does not store function and macro definitions on a stack.
However, what you still could do is either one of the following or ma
On 5/23/2011 2:15 PM, sind...@gmail.com wrote:
> I have the below directory structure for Fortran code which has very
> basic dependencies, I am not able to get CMake to recognize the
> dependencies automatically without me explicitly having to specify it
> using add_dependencies or target_link_lib
Hi guys,
I just discovered the --warn-uninitialized flag to cmake, and in the
process found some really nasty bugs. Is there any way to enable this
from the CMakeLists.txt files? Is there a corresponding
--error-uninitialized value?
Thanks
/Johan
___
Po
I
have managed to resolve this issue. The problem was that I only ran
cmake once. Running it a second time before running mingw32-make
produced the correct results. I guess this has something to do with the
cache not having all the right values after just one run.
Stiaan
On 05/19/2011 05:53 P
17 matches
Mail list logo