On Fri, 27 Sep 2002, Ken Murchison wrote:
> > were looking at a path I never specified ( /usr/local/include ) and reading
> > the include files from there, instead of the path I did specify:
> > --with-dbdir=/opt/berkeleydb
Now... I'm just guessing at the problem here. Is he saying that he has a
different version of berkleydb in /usr/local than the one he's trying to
build against, which is in /opt/bekreleydb, and that having
/usr/local/include in the search path first is breaking the configure
process?
> A lot of bitching, and no proposed fixes. It works for me, and I'm sure
> it works for CMU, otherwise it would've been fixed already. Since I
True, but he does seem to be bringing up an important stylistic issue in
how configure processes options, perhaps even in how it arranges the build
environment.
I won't go into the issue of whether or not /usr/local/include should be
used, as he never specifies whether he'd changed his prefix to something
else and it seems quite reasonable to treat the include and lib areas of
the prefix as general system areas.
However it does seem that when explicit paths are called for certain
componants they should be placed in line before the assumed system paths.
That is to say, if you want to build and link against a libfoo in
/snert/myjunk/foo-8.3.4 then this should be placed in the relevant paths
before the include and lib dirs in /usr or /usr/local that are added
automatically.
Cheers.
-----
/"\ Michael Newlyn Blake <[EMAIL PROTECTED]> \ oo
/ \ \____|\mm
\ / GAT d- s-:++ a? C+++ UL++++ P+ L+++ E--- W++ //_//\ \_\
\ / N+ o-- K--- w--- O- M V-- PS+ PE Y+ PGP t++ /K-9/ \/_/
X 5+ X+ R tv+ b+++ DI++ D+ G-- e h--- r+++ y+++ /___/_____\
/ \ -----------
ASCII Ribbon Campaign Against HTML Mail
