Solved: Compiling fresh Sendmail on RedHat 9.0

Compiling Sendmail on RedHat 9.0 was fun - definitely
worth posting a quick summary.

cd /usr/src/
# download fresh sendmail
tar xvzf sendmail.8.13.3.tar.gz
cd sendmail-8.13.3
./Build
./Build install
cd ..
/etc/init.d/sendmail start

After a default compilation, Sendmail 8.13.3
complains that "class hash not available".
It took me some time to accomplish the following
building procedure:

/etc/init.d/sendmail stop

Download fresh Berkeley DB (libdb), at the time of this
writing the fresh one is version 4.3.27. This can be
obtained at http://www.sleepycat.com/
It appears that Sendmail fails to build against
BDB < 2.0 and 4.0 - 4.1.xx.
RedHat comes with libdb 4.0.

tar xvzf db-4.3.27.tar.gz
cd db-4.3.27
# what ho, no Makefile, no ./configure, no INSTALL ?
cd build_unix
../dist/configure
make
make install
cd ../..

This installed berkeley DB. It installs into its very
own directory, /usr/local/BerkeleyDB.4.3/ which is a
good thing. The RedHat distro is compiled against 4.0,
and we only want Sendmail to know about the fresh 4.3
- other apps compiled against 4.0 could possibly be confused.

# Let the system-wide ld know about the new library.
echo "/usr/local/BerkeleyDB.4.3/lib" >>/etc/ld.so.conf
ldconfig

cd sendmail-8.13.3

Now create a file under ./devtools/Site/ called site.config.m4 .
Check site.config.m4.sample in that same directory for a bit
of an explanation / example. Our custom site.config.m4 should
contain these two lines:

PREPENDDEF(`confLIBDIRS', `-L/usr/local/BerkeleyDB.4.3/lib')
PREPENDDEF(`confINCDIRS', `-I/usr/local/BerkeleyDB.4.3/include')

Obviously this should pass the right options to the compiler
and linker. Now that we have the site config, we can re-try
the build. Interestingly, if you run just ./Build, the updated
config won't take effect... After some more reading, you try
./Build -f /usr/src/sendmail-8.13.3/devtools/Site/site.config.m4
which shouts that it can't overwrite previously parsed config!
Fortunately, the error message suggests the right Build option of "-c".

./Build -c
./Build install
/etc/init.d/sendmail start

Now it should launch just fine.

Hope this helps

Frank Rysanek


Frantisek Rysanek

Frantisek Rysanek wrote:

> Compiling Sendmail on RedHat 9.0 was fun - definitely
> worth posting a quick summary.

NO package manager on your system?

Wow, what a mess!

FWIW, I like to build from SRPMs myself. All the benefits of
"home-built" code PLUS package management.

One day "real soon now" I'm going to learn how to make SRPMs from fresh
source. It's on my to-do list.

In the meantime, I just have to make do with having Sendmail 8.13.1
instead of 8.13.3.

> NO package manager on your system?
>
> Wow, what a mess!
>
I hardly ever need to uninstall things on my production
machines. OTOH, I want fresh stable releases of software
on my production machines, to avoid old known exploits.

Package management systems are good if you need
to maintain large modular distro's - or if you're a user
who can't cope with make, gcc et al.
As your particular system install gets increasingly different
from the original distro, building from source becomes
increasingly safer.

OTOH, publishing my own RPMs would wreak my mess
and human errors unto unsuspecting other people...
I prefer to publish source code when I write some.

In my case, stringent package management equals
unnecessary overhead.

Frank Rysanek

On Tue, 18 Jan 2005 00:09:49 -0800, Frantisek.Rysanek wrote:
>> NO package manager on your system?
>>
>> Wow, what a mess!
>>
> I hardly ever need to uninstall things on my production
> machines. OTOH, I want fresh stable releases of software
> on my production machines, to avoid old known exploits.
>
> Package management systems are good if you need
> to maintain large modular distro's - or if you're a user
> who can't cope with make, gcc et al....

I disagree. I used to build from tarballs on SunOS. I like having RPM
available to bundle up stuff that I install/deinstall (e.g. latest version
has a bug, so I can roll back to the previous one). Also, RPM has
verification capabilities (e.g. "rpm -Va" or "rpm -V <pkgname>") which can
check that nothing has clobbered the components of a package and/or there
are no conflicts between packages. I like having those abilities.

> As your particular system install gets increasingly different
> from the original distro, building from source becomes
> increasingly safer.

....but your system may become more and more "twisted" away from the
consistency of the original distro. I have seen this with ad hoc updates
of packages to bleeding edge releases required for other software I want.

> OTOH, publishing my own RPMs would wreak my mess
> and human errors unto unsuspecting other people...
> I prefer to publish source code when I write some.

Please, at least include a .spec file for others' convenience. While
some/many of the .spec files out there are not very pretty/good, they are
almost always better than nothing. Why make everyone redo that work?

> In my case, stringent package management equals
> unnecessary overhead.

To each his own. Do you drive without seatbelts, too? YMMV

--
Juhan Leemet
Logicognosis, Inc.