Re: [fetchmail-users] fetchmail 6.2.9-rc3 available

[Matthias A. <mat...@gm...>]

On Mon, 19 Sep 2005, Thomas Wolff wrote:

> > I seek everyone to test it out, report remaining bugs, update outdated
> > translations or send patches for documentation or report inconsistencies
> > (including formatting!) in the documentation.
> 
> The following error remains on SunOS:
> gcc -I/home/demsn702/opt/openssl-0.9.8/include -I/usr/kerberos/include 
> -g -O2 -L/home/demsn702/opt/openssl-0.9.8/lib  -o fetchmail  socket.o 
> getpass.o pop2.o pop3.o imap.o etrn.o odmr.o fetchmail.o env.o idle.o 
> options.o daemon.o driver.o transact.o sink.o smtp.o uid.o mxget.o 
> md5ify.o cram.o kerberos.o gssapi.o opie.o rpa.o interface.o netrc.o 
> unmime.o conf.o checkalias.o smbdes.o smbencrypt.o smbmd4.o smbutil.o 
> lock.o rcfile_l.o rcfile_y.o norm_charmap.o getaddrinfo.o getnameinfo.o 
> libfm.a  stpcpy.o  -lnsl -lsocket  -lintl -lresolv -lssl -lcrypto
> Undefined                       first referenced
>  symbol                             in file
> dlclose                             /home/demsn702/lib/libcrypto.a(dso_dlfcn.o)  (symbol belongs to implicit dependency /usr/lib/libdl.so.1)

Does adding -ldl to LIBS or LDFLAGS help?

> Also, as I had noted before, fetchmail --ssl apparently depends on 
> IMAPS being known to the system as a service - probably by listing it 
> in /etc/services. If this is not the case, getaddrinfo will fail.
> Now fetchmail seems to be the only tool that enables command line users 
> to set up a working mail environment on a system which is not 
> otherwise administrated for handling mail (together with ssmtp).
> Thus it should not depend on proper system configuration in any respect - 

Well, fetchmail isn't supported to work on arbitrarily broken systems
that are years past their end of life. Let's see if we can get it to
work without hardcoding this information...

> it should work even if getaddrinfo does not "know" IMAPS!

...so does it work to specify the port explicitly on the command line?
"--port 993" should work. I don't feel like hacking port numbers in
opaque data - that is not the intention of protocol independence
patches.

-- 
Matthias Andree