On Thu, 2 Jul 2009, Mark Taylor wrote:
> you may remember the issue with xerces-c and libcurl erroneously picking
> up a library from /usr/local when it should have got one from closer to
> home from a while back (see below). I've come across what I think is
> another instance of this. While rebuilding vtk to use latest gaia-vo,
> the build kept trying to use /usr/local/lib/libXft.so, though that has
> the wrong architecture. Eventually I edited vtk/VTK/CMakeCache.txt by
> hand and replaced the offending reference with
> /usr/X11R6/lib64/libXft.so and the build went OK.
>
> Investigate and fix if you think it's worth it.
Hi Mark,
OK, I had a look and wished I hadn't. I can make the build pick up this
library from a non-standard place, but only by removing the standard
version, so I'm a bit stumped.
One possibility is that you have /usr/local/lib on your PATH (yes PATH not
LD_LIBRARY_PATH), weird but that would do it. Failing all that can you not
get rid of these 32bit libraries? They are clearly not right for this
system and probably always out of date.
BTW, in case you're wondering it doesn't seem to be possible to get cmake
to check that the library is compatible, it just looks for path names and
throws "64" on the end of the directories when it thinks this is a 64bit
OS.
Yuk,
Peter.
|