On Thu, 2 Jul 2009, Peter W. Draper wrote:
> 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
nope, that's not it.
> rid of these 32bit libraries? They are clearly not right for this system and
> probably always out of date.
They're there because they are on a NFS-mounted drive which does have
some software I want. However, if it's tough to fix, I'm not suggesting
you try to. I can rename that drive or unmount it during the config
or whatever - once diagnosed it's not hard to work round.
> 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.
I was wondering, but not deeply enough to wade into cmake internals...
Thanks for looking anyway
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|