Hi all.
I'm having some troubles building Sendmail 8.11.1 on Tru64 UNIX 4.0F
(a.k.a. Digital UNIX (a.k.a. DEC OSF/1)).
When Build enters ./obj.obj.OSF1.V4.0.alpha/sendmail and gets to linking
phase, I get the following:
-----------------------------------------------------------------------
cc -std1 -Olimit 1000 -o sendmail -L/usr/shlib -L/usr/local/lib main.o
alias.o arpadate.o bf_portable.o clock.o collect.o conf.o control.o
convtime.o daemon.o deliver.o domain.o envelope.o err.o headers.o
macro.o map.o mci.o milter.o mime.o parseaddr.o queue.o readcf.o
recipient.o savemail.o sfsasl.o shmticklib.o srvrsmtp.o stab.o stats.o
sysexits.o timers.o trace.o udb.o usersmtp.o util.o version.o
-lsasl ../libsmutil/libsmutil.a -lresolv -ldb-3
ld:
../libsmutil/libsmutil.a(snprintf.o): vsnprintf: multiply defined
../libsmutil/libsmutil.a(snprintf.o): snprintf: multiply defined
*** Exit 1
Stop.
-----------------------------------------------------------------------
Well, the problem seams to arise from snprintf function. It is present
in ../libsmutil/libsmutil.a(snprintf.o) and it is present on Tru64 UNIX
in one of the system libraries (libc.so, I suspect).
Source ../libsmutil/snprintf.c states this:
* Original:
* Patrick Powell Tue Apr 11 09:48:21 PDT 1995
* A bombproof version of doprnt (sm_dopr) included.
* Sigh. This sort of thing is always nasty do deal with. Note that
* the version here does not include floating point...
*
* snprintf() is used instead of sprintf() as it does limit checks
* for string length. This covers a nasty loophole.
*
* The other functions are there to prevent NULL pointers from
* causing nast effects.
and
#if !HASSNPRINTF && !SNPRINTF_IS_BROKEN
-----------------------------------------------------------------------
QUESTION: Since Tru64 UNIX seams to have snprintf() can I just define
HASSNPRINTF?
Is it broken?
Any other sendmail build tips for T64 4.0F?
Nix.
--
No animals were harmed during the production of this message.
Received on Tue Oct 24 2000 - 06:34:39 NZDT