Mark wrote:

I have done this upgrade path for BerkeleyDB and Perl several times;
from 1.85 -> 4.1 -> 4.2, and now -> 4.4.20. It has always worked well.
Even now it compiles just fine. It just isn't stable anymore.

If someone out there has an idea, I'd really like to know.
I don't have any good answers for you, sorry. Probably no-one is answer-
ing because no-one active is doing anything with these particular pack-
age versions.

But, there is a port of BerkeleyDB (databases/p5-BerkeleyDB) which would
save you from having to mess around configuring config.in yourself. Just
set something like WITH_BDB_VER=44 (or 42 or...) in pkgtools.conf (for
portupgrade) or make.conf or on the command line. The port doesn't seem
to do any local patches so I wouldn't expect it to work any better for
you, unless you have been doing something wrong.

Thanks for answering. Really appreciate it.

I actually already tried p5-BerkeleyDB too. Had high hopes for it. It took
a good 10 minutes or so to compile a new gcc, 3.2.23, first; but after
that, everything went well. Except that it shows the same behavior.
Compile goes fine; "make tests" too. But my app core dumps every, say,
30 times it accesses BerkeleyDB.
Not sure why p5-BerkeleyDB thinks it needs a specific gcc, though 3.2.23 is the version I have anyway (FreeBSD 5.4) so I didn't know to warn you :-(

If you want to pursue further here are some suggestions that I might try:

1) Make sure you are not doing anything non-standard like using a different thread library, or different CFLAGS. You never know...

2) Try using a different underlying database type if you can. E.g. if you use hash, then try btree or vice versa

I don't know what your apps do, but make sure for example, that if you can have multiple instances which can write to the db at the same time that your are locking correctly. In 1.85 compatibility usage that means locking a separate file with e.g. flock and *not* locking the database file itself which doesn't work right.

Waiting for 4.5 is an option, but I would worry that whatever change in 4.4 is making your app crash might also bite in 4.5. I could find nothing on google about perl+4.4 core dumping so I would harbour a suspicion that it is something about the way you are using BerkeleyDB which is causing the trouble. I could be wrong of course :-)

--Alex

PS I know there isn't a port yet, but you could just try compiling 4.5 from the sleepycat sources. The port for 4.4 doesn't look like it does anything sophisticated: just applies the latest patches from sleepycat, sets up some configure args, and has one small patch to dist/configure which changes -avoid-version into -version-info 0:0:0 in a couple of places.

PPS If I have a chance at some point to try my software with 4.4 I will let you know how I get on. Regrettably, I don't have time right now to try it.



_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to