Bug 191978 - mail/fetchmail won't build on FreeBSD 10.x with Kerberos support disabled
Summary: mail/fetchmail won't build on FreeBSD 10.x with Kerberos support disabled
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-20 02:11 UTC by Jeremy Chadwick
Modified: 2014-08-12 18:08 UTC (History)
2 users (show)

See Also:


Attachments
Makefile patch (392 bytes, patch)
2014-08-11 16:45 UTC, Jeremy Chadwick
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Chadwick 2014-07-20 02:11:40 UTC
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).
Comment 1 Jeremy Chadwick 2014-07-20 02:16:14 UTC
Patch (output of "svn diff") is also available here for download:

http://jdc.koitsu.org/freebsd/191978/Makefile.diff

There may be a "cleaner" or better way to do this, by the way, and if so I totally suppport that.  (Give me a diff/patch and I can test it if needed).  But reproducing the problem should be as easy as:

- Adding WITHOUT_KERBEROS=true to /etc/src.conf
- Rebuilding world
- Using make delete-old and make delete-old-libs
- Try to build ports/mail/fetchmail

Note: I don't think the GSSAPI option really influences this problem, at least not to the fetchmail configure script, but I cannot imagine someone disabling Kerberos support system-wide then trying to use GSSAPI in all their ports (it would fail).  So the GSSAPI empty() check is basically to ensure that we don't break things for people who DO have Kerberos enabled.  But as I said, there may be a more proper logic/methodology to solving this, in which case great!
Comment 2 Jeremy Chadwick 2014-07-20 02:25:24 UTC
I just realised a simpler approach might be this:

post-patch:
.if !exists(/usr/lib/libcom_err.so)
        @${REINPLACE_CMD} -e "s,-lcom_err,,g" ${WRKSRC}/configure
.endif

Since this file would exist on FreeBSD 9.x (with or without WITHOUT_KERBEROS=yes in src.conf), but would be excluded on FreeBSD 10.x systems using WITHOUT_KERBEROS=yes.

I'll leave it up to the port maintainer to decide which methodology is preferred, or possibly a combination of multiples.
Comment 3 John Marino freebsd_committer 2014-07-20 14:26:55 UTC
notify maintainer
Comment 4 Corey Halpin 2014-07-20 15:15:43 UTC
I'd prefer this methodology:

post-patch:
.if !exists(/usr/lib/libcom_err.so)
        @${REINPLACE_CMD} -e "s,-lcom_err,,g" ${WRKSRC}/configure
.endif

As for the "python 2.0 or later not found", this is expected if you have the X11 option disabled.  This is "to defeat Python byte-code compilation" as described in fetchmail's README.packaging:
  https://gitorious.org/fetchmail/fetchmail/source/ff83a54b4f48010c4477b18b9551cd513d649f8e:README.packaging

The '-I/usr/kerberos/include' is definitely more concerning... I'll give that a look.

As for this bug, I'm happy to approve the above post-patch as a fix.
Comment 5 Jeremy Chadwick 2014-07-20 18:03:00 UTC
Cool, understood.  I've provided an updated svn diff / patch here which does exactly what's stated in c#4:

http://jdc.koitsu.org/freebsd/191978/Makefile.ver2.diff
Comment 6 John Marino freebsd_committer 2014-08-11 11:02:26 UTC
Corey, do you approve the latest patch?
Comment 7 John Marino freebsd_committer 2014-08-11 11:02:58 UTC
Jeremy, you need to attach patches to the PR.  Thanks!
Comment 8 Corey Halpin 2014-08-11 11:09:40 UTC
Yes, I approve the patch at
 http://jdc.koitsu.org/freebsd/191978/Makefile.ver2.diff
Comment 9 John Marino freebsd_committer 2014-08-11 11:17:28 UTC
Okay, I see the diff is only a few lines long.  It would still be nice to get it as an attachment, but I'll move this to patch-ready in any case.
Comment 10 Jeremy Chadwick 2014-08-11 16:45:13 UTC
Created attachment 145670 [details]
Makefile patch

Sorry about not adding it as an attachment! Doh! Here it is.
Comment 11 commit-hook freebsd_committer 2014-08-12 11:22:14 UTC
A commit references this bug:

Author: marino
Date: Tue Aug 12 11:22:02 UTC 2014
New revision: 364693
URL: http://svnweb.freebsd.org/changeset/ports/364693

Log:
  mail/fetchmail: Fix on F10 when system is built without Kerberos

  PR:		191978
  Submitted by:	Jeremy Chadwick
  Approved by:	maintainer (Corey Halpin)

Changes:
  head/mail/fetchmail/Makefile
Comment 12 John Marino freebsd_committer 2014-08-12 11:24:07 UTC
I couldn't easily test it, so I committed it as.  I didn't see the need for a portrevision bump since it either built or it didn't.  Anyway, fix is in.
Comment 13 Jeremy Chadwick 2014-08-12 18:08:13 UTC
For John (as I was a ports committer in the past): agreed, bumping PORTREVISION for this is not needed since anyone on 10.x using WITHOUT_KERBEROS wouldn't have been able to build the port anyway and for quite some time.  :-)

Thank you everyone!