Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] crash on db dump (still)

2007-08-31 by Jeff A. Earickson

On Fri, 31 Aug 2007, manu@... wrote:

> Date: Fri, 31 Aug 2007 14:42:40 +0200
> From: manu@...
> Reply-To: milter-greylist@yahoogroups.com
> To: Milter Greylist list <milter-greylist@yahoogroups.com>
> Subject: Re: [milter-greylist] crash on db dump (still)
> 
> Jeff A. Earickson <jaearick@...> wrote:
>
>> After a day of running this patch, I have backed it out.  It did not help
>> and may have made things worse.  I had a dumpfile crash 7 times yesterday
>> and 6 times so far since midnight.  I have a cron job that restarts
>> milter-greylist if it disappears from the process list.
>
> Do you have the possibility of building a 64 bit binary, so that we can
> completely rule out the Solaris-specific stream limit?
>

Hi,

I have struggled with this a great deal today, using gcc -m64.  My first
error was configuration of milter-greylist:

checking for smfi_register in -lmilter... no
checking for smfi_register in -lmilter -lsm... no
checking for smfi_register in -lmilter -lsmutil... no
Required libmilter not found. Use --with-libmilter

This was something I did not get with 32 bit.  I found an old version
of libmilter in /usr/lib, and realized (a) libmilter was out-of-date
relative to sendmail, (b) it had been built with cc, not gcc, and (c)
it was a 32-bit library.  So I went back to my sendmail code and 
realized that libmilter does not automatically get built and installed
with sendmail.

So I tried to build a 64-bit gcc shared library version of libmilter
for use here.  The URL:

http://www.technoids.org/libmilter.so.html#Appendix

gave me a general approach on how to tackle this.  I'm to the point
where the .c files for libmilter compile just fine, but the shared
library won't link:

gcc -O2 -I. -I../../sendmail   -I../../include  -I/opt/BerkeleyDB/include -I/opt/sasl/include/sasl -I/opt/openssl/include -I/usr/local/include -DSOLARIS=21000 -DNETINET6 -UNIS -UNISPLUS -DNEWDB -DSASL=2 -DSTARTTLS -DSM_CONF_LDAP_MEMFREE -DTCPWRAPPERS -DHASURANDOMDEV -DIDENTPROTO=0 -DDSN=0 -DNOT_SENDMAIL -Dsm_snprintf=snprintf -m64 -g -D_REENTRANT -DXP_MT  -c  strl.c
gcc -lpthread -Wl,"-64" -G -o libmilter.so -h libmilter.so. main.o engine.o listener.o worker.o handler.o comm.o smfi.o signal.o sm_gethost.o monitor.o errstring.o strl.o 
ld: fatal: file /usr/local/lib/gcc/sparc-sun-solaris2.10/4.2.0/crt1.o: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to libmilter.so

or:

gcc -lpthread -G -o libmilter.so -h libmilter.so. main.o engine.o listener.o worker.o handler.o comm.o smfi.o signal.o sm_gethost.o monitor.o errstring.o strl.o 
ld: fatal: file main.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to libmilter.so

Obviously, I'm mixing 32 and 64 bit binaries here but I don't know
why (nor how to fix it with loader options).  I googled on "wrong
ELF class" but didn't find an answer...

Visions of Will Farrell in his Elf outfit come to mind here.  :)

Any help here?

Jeff Earickson
Colby College

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.