On Montag, September 3, 2001, at 04:10 Uhr, Sander Striker wrote
>>> I had the following problems when compiling:
>>> --with-berkeley-db=/usr/local/BerkeleyDB.3.3 does not seem to work, I
>>> had to create a link from the db sources to db
>> Hmm. Can you locate the relevant section of your config.log and post
>> Or better yet: figure out why it didn't like that path?
> I had the same problem. Haven't figured out what it is yet. The
> script claims to be looking in '/opt/db' for 3.3.11, but isn't finding
> although it is installed there. FYI, this is with the M3 tarball on a
> linux 2.4.3 system. I haven't tried the checked out copy with an
> db path yet.
Actually I got it to work with v22 from the repository. So it was either
the M3 or I had something bad in the config.cache.
>>> tried to use the --program-suffix=SUFFIX option, but the option seems
>>> to be ignored.
>> Yup. I took it a look. It is ignored... Can you provide a patch? I'd
>> you would want to AC_SUBST(program_suffix) into the Makefile, then
>> gen-make.py to append $(program_suffix) on the end of executable
>> names when it generates a LINK line.
>>> Workaround: move the SVN directory out of the way.
>>> Wouldn't it be better in general to use .svn or .SVN instead of SVN?
>> I like .svn. The only reason we have SVN for the name is a legacy
>> similarity to CVS. I can't really think of a reason to keep them
> I personally don't think we need to stay in the CVS mindset. If it
> count I would vote +1 for moving from "SVN" to ".svn". It is only 1
> And possibly a quick directory rename script for the developers.
My vote is for .svn instead of SVN, too.
Logic United GmbH
Received on Sat Oct 21 14:36:39 2006