On Mon, 8 Jun 2009, Peter W. Draper wrote:
> On Thu, 4 Jun 2009, Mark Taylor wrote:
>
> > there seems to be an unhelpful instance of the path /usr/local/ being
> > hardcoded into the configuration of thirdparty/apache/xerces-c
> > package.
> >
> > I was building in the normal way, and it went OK until the xerces-c
> > build failed because it was looking at a /usr/local/lib/libcurl.so,
> > which happened to have the wrong architecture (it's mounted from a
> > 32-bit machine, and I'm running a 64-bit one). It should have picked
> > up the libcurl from /usr/lib64. I don't believe that /usr/local(/lib)
> > is referenced in any of my environment variables.
> >
> > If I unmount /usr/local at configure time, the build goes OK.
> > I'm not certain this constitutes a bug, but I think it would go
> > smoother if either (a) /usr/local wasn't hard coded into the
> > xerces-c configuration machinery or (b) the config machinery
> > was smart enough to notice that the /usr/local/lib/libcurl is
> > inappropriate for the current build.
>
> It's a bit of a mess. The curl library is found by locating the package
> include file and assuming that will be OK. Sorting this out properly looks
> like a pain, so I've just prefered looking in /usr over /usr/local, fingers
> crossed that will work more often. You'll need to update the xerces-c
> submodule to test this:
>
> % git pull --rebase
> % ./update-modules
thanks Peter, I think that's done the trick.
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|