fetchmail's configure/configure.ac makes many idiotic assumptions when it comes to FreeBSD.

At some point within FreeBSD 10.x, someone decided to remove libcom_err from being built if WITHOUT_KERBEROS=true is used in src.conf (or at least that's my speculation -- I use the same setting in src.conf on FreeBSD 9.x and libcom_err still gets built).  That change is fine.

But fetchmail explodes horribly during configure when the FreeBSD 10.x system lacks libcom_err.  The error is very confusing but I'll explain it:

root@icarus:/usr/ports/mail/fetchmail # make
...
checking size of short... configure: error: in `/usr/ports/mail/fetchmail/work/fetchmail-6.3.26':
configure: error: cannot compute sizeof (short)
See `config.log' for more details
===>  Script "configure" failed unexpectedly.

One's first inclination is to think this is a clang vs. gcc issue, but that's incorrect.  The problem is actually that the "sizeof short" test uses the compiler to build a binary, and during link-time uses -lkvm -lcom_err blindly.  config.log shows this:

configure:8731: checking size of short
configure:8736: cc -o conftest -O2 -pipe -fno-omit-frame-pointer -march=core2 -fno-strict-aliasing   -L/usr/local/lib -Wl,-rpath,/usr/lib:/usr/local/lib conftest.c -lcrypt  -lkvm -lcom_err >&5
/usr/bin/ld: cannot find -lcom_err
cc: error: linker command failed with exit code 1 (use -v to see invocation)
configure:8736: $? = 1
configure: program exited with status 1
configure: failed program was:

And the relevant code in configure:

# Check for FreeBSD special case: more libs needed
freebsd*)
    { $as_echo "$as_me:${as_lineno-$LINENO}: found FreeBSD - Adding -lkvm -lcom_err to standard libraries" >&5
$as_echo "$as_me: found FreeBSD - Adding -lkvm -lcom_err to standard libraries" >&6;}
    LIBS="$LIBS -lkvm -lcom_err"
    ;;

We cannot fix this in configure.ac + rerun autoconf because of massive insanity between autotools versions (go ahead, add USE_AUTOTOOLS=autoconf, see what happens).  So we have to patch this nonsense in configure directly.

My methodology of fixing this is very rude/aggressive -- literally remove all mentions of -lcom_err within the configure script during post-patch time, but only if the GSSAPI port option isn't set and FreeBSD 10.x is used.  (There are pieces specific to OpenBSD which would break, but this isn't OpenBSD...)

The patch:

Index: Makefile
===================================================================
--- Makefile    (revision 362293)
+++ Makefile    (working copy)
@@ -91,6 +91,15 @@
 PORTDOCS+=     README.NTLM
 .endif

+# FreeBSD 10.x with GSSAPI support disabled does not build libcom_err, but
+# fetchmail's configure blindly assumes the library exists on FreeBSD.
+# Without this, configure-time fails when trying to "detect size of short",
+# which is just because it's the first compiler test that uses -lcom_err
+post-patch:
+.if empty(PORT_OPTIONS:MGSSAPI) && ${OSVERSION} >= 1000000
+       @${REINPLACE_CMD} -e "s,-lcom_err,,g" ${WRKSRC}/configure
+.endif
+
 post-build:
        @${MAKE} -C ${WRKSRC} check

Footnote: I would strongly suggest the port maintainer take the time to review every single line that is output during the configure phase, in addition to the make phase.  There are very uncomfortable things being shown, such as "python 2.0 or later not found" (when python 2.7 is installed on the system), and heavy use of -I/usr/kerberos/include despite that not being a valid path on FreeBSD (or even existing).  Gut feeling is that this is all fetchmail autoconf stupidity, but someone really should look into discussing it with the fetchmail maintainer(s).