UPGRADING BERKELEY DB:
This is the summary for my posting (included at the bottom of
this email) regarding using a later version of Berkeley DB
(either version 2 or 3) alongside the pre-installed version 1.85
that comes with Tru64 unix.
My solution was to keep libdb.so and libdb.a in /usr/local/lib
and still allow the old v1.85 libdb's to stay in /usr/shlib and
/usr/lib and /usr/ccs/lib.
I got two replies and both suggested this was a good solution,
but I also got some helpful warnings which bring attention to
quirks that could save you a lot of time if you are aware of them
and the questions also raised issues concerning sendmail.
The main point was you need to ensure that the right libraries
are selected for linking.
The following interesting thought was also included...
>"Software is like sex, it's better when it's free." (Linus Torvalds)
Thanks to both Tim and Nix and also to my assistant at Compaq
support who made some enquiries for me.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
MAKE SURE YOUR LINKER PICKS THE RIGHT LIBRARY:
>Familiarize yourself with the `ld' man page, especially the
>-oldstyle_liblookup option. The default behavior of Compaq's
>linker is different from that of `ld' on most other Unixes (not
>counting IBM's AIX, where the linker is *really* strange),
>because the linker will prefer a shared library if it can find
>one *anywhere* in directories it's searching, even if it finds a
>static library in a directory searched earlier. The
>`-oldstyle_liblookup' undoes this oddity, and returns the linker
>to the more common behavior, where it uses the first shared or
>archive library it finds.
>
>The upshot is that if you install updated copies of libraries
>(like Berkeley DB 2.x or later) that "shadow" system libraries
>*and* the local copy exists in only the static version, then
>you'll probably want to make a habit of using
>`-oldstyle_liblookup' as one of your LDFLAGS.
>
>BTW, I reported this situation to the folks from SleepyCat and
>they said they would add it to the FAQ on their web site, but I
>don't think they ever did.
>
>Tim Mooney
>mooney_at_dogbert.cc.ndsu.NoDak.edu
>Information Technology Services (701) 231-1076 (Voice)
>Room 242-J1, IACC Building (701) 231-8541 (Fax)
>North Dakota State University, Fargo, ND 58105-5164
--------------------------------------------------------------------------
--------------------------------------------------------------------------
NIKOLA ALSO WARNS:
>Well, just make sure you link the right ones.
>
>Nikola.Milutinovic_at_ev.co.yu
>EPS Elektrovojvodina
--------------------------------------------------------------------------
--------------------------------------------------------------------------
POSSIBLE REASONING BEHIND NOT UPGRADING BERKELEY DB IN THE OS:
>Licensing, I would guess. Last time I checked, Berkeley DB 2.x
>and later has a license that is more restrictive than the 1.x
>license. Until just recently Berkeley DB 2.x was a moving
>target, too, so Compaq's engineers may have chosen to stick with
>an older version (where they know what the bugs are) rather than
>risk a "better" version, with all the unknowns.
>
>Tim Mooney mooney_at_dogbert.cc.ndsu.NoDak.edu
I also rang Compaq Tru64 support on our software contract and was
informed that due to requirments to safely integrate security
software within the OS with the later versions of Berkeley DB,
that there were no plans to upgrade Berkeley DB within the OS
until version 5.1, which might be around the end of this year.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
WHICH VERSION OF BERKELEY DB TO USE WITH SENDMAIL?:
>Are you sure sendmail will work with new version of Berkeley DB?
>I thought 1.85 was supported and not the later ones.
>
>Why is sendmail still using 1.85? It clearly states that 1.85
>version is supported and later are not. At least 8.9.3.
>
>Well, I've never seen a core dump of sendmail (about two years)
>and I use Digital's provided DB 1.85 and use cc.
>
>Nikola.Milutinovic_at_ev.co.yu
Although I was constrained to upgrade Berkeley DB because certain
software that was to be installed actually required a much later
version, I think there is still a choice when compiling sendmail.
However, there are questions about this.
FAQ AT SENDMAIL.ORG:
As of release 8.9.X of sendmail, db 1.85 is no longer needed, as
support for db 2.X is included (starting with 2.3.16). More
details are given at Q3.25. The rest of this answer only applies
if you have not yet upgraded to 8.9.X .
FAQ AT SENDMAIL.ORG:
Sendmail 8.8 only supports Berkeley DB 1.85. It will not work
with newer Berkeley DB versions, even in compatibility mode.
Sendmail 8.9, however, does include support for Berkeley DB 2.X,
starting with 2.3.16.
README FROM SENDMAIL 8.9.3:
If you are using Berkeley DB versions 1.85 or 1.86, you are
*strongly* urged to upgrade to DB version 2, available from
http://www.sleepycat.com/. Berkeley DB versions 1.85 and 1.86
are known to be broken in various nasty ways (see
http://www.sleepycat.com/db.185.html), and can cause sendmail to
dump core. In addition, the newest versions of gcc and the
Solaris compilers perform optimizations in those versions that
may cause fairly random core dumps.
I think Nikola may have a point. This warning use strong language
but in practice I have not seen sendmail dump core. However, I
have heard that sendmail is also apt to fail silently without
terminating, which means you'll never know it's not working. My
main reason for upgrading would have to be possible security
concerns.
Anil
--------------------------------------------------------------------------
--------------------------------------------------------------------------
ORIGINAL QUESTION:
As a recent requirement for some software we want to run I have
installed version 2.7.7 of Berkeley DB. Trouble is there is an
existing libdb.so in /usr/shlib (and additional libdb.a and db.h
in the other standard locations). The existing libdb.so is a
previous version, I suspect 1.85, and won't stand being changed.
I therefore installed our version 2 Berkelely DB libraries in
/usr/local/lib and the include in /usr/local/include. So far my
compilations that use Berkeley DB have automatically referenced
the later version in these locations since the make files
actually look there first.
I am confident about compiling sendmail with this installation of
Berkeley DB, even if I have to change the make file, but I did
previously have trouble getting it to catch the new version of
Berkeley DB (I think I didn't have the libdb.so last time, and
was trying to get it to use the libdb.a).
I was just wondering in anticipation of any more difficulties for
myself whether any other managers have had trouble in this area,
and whether they can therefore pass on any tips or warnings.
Also, I was wondering if any one had an opinion on why Compaq
Unix is still using Berkeley DB version 1.85 when there is now
two major version number upgrades since that release (we are now
up to version 3).
Thanks
Anil (Neil) Gulati
ngulati_at_scu.edu.au
anil_at_rubios.scu.edu.au
Southern Cross University
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Received on Mon Mar 13 2000 - 03:45:41 NZDT