While investigating why my fetchmail wasn't connecting to gmail, I discovered that it lacked ssl. I'd modified CONFIGURE_ARGS= --enable-opie --enable-RPA --enable-SDPS \ --with-ssl=${OPENSSLBASE} to CONFIGURE_ARGS= --without-hesiod --enable-fallback=no --with-ssl=${OPENSSLBASE} but ssl still wasn't included. After a lot of head-scratching I moved CONFIGURE_ARGS from line 32 to 75, immediately before #.include <bsd.port.options.mk> By moving this line, ssl was included. Quite the mystery but the issue isn't that I modified it, it is that by moving this line later in the script that its settings were "as they should be", namely: # make -C /usr/ports/mail/fetchmail/ -VCONFIGURE_ARGS --without-hesiod --enable-fallback=no --with-ssl=/usr/local --disable-nls --disable-NTLM --disable-POP2 PYTHON=: --without-gssapi --prefix=/usr/local ${_LATE_CONFIGURE_ARGS} instead of --disable-nls --disable-NTLM --disable-POP2 PYTHON=: --without-gssapi --prefix=/usr/local ${_LATE_CONFIGURE_ARGS} This may be a bigger problem than just mail/fetchmail. ----------------------- svnlite diff --- /usr/ports/mail/fetchmail/Makefile (revision 442739) +++ /usr/ports/mail/fetchmail/Makefile (working copy) @@ -26,9 +26,12 @@ SUB_FILES= pkg-message GNU_CONFIGURE= yes -CONFIGURE_ARGS= --enable-opie --enable-RPA --enable-SDPS \ - --without-hesiod --enable-fallback=no \ - --with-ssl=${OPENSSLBASE} + +# 20160412 Next two lines changed. opie prevented a build; and unusual errors with clang so CONFIGURE_ARGS= --enable-opie --enable-RPA --enable-SDPS +# USE_GCC= any +#CONFIGURE_ARGS= --enable-opie --enable-RPA --enable-SDPS \ +CONFIGURE_ARGS= --without-hesiod --enable-fallback=no --with-ssl=${OPENSSLBASE} +# --with-ssl=${OPENSSLLIB} CONFIGURE_ENV= ac_cv_have_decl_SSLv2_client_method=no LDFLAGS+= -L${LOCALBASE}/lib @@ -68,6 +71,7 @@ design-notes.html fetchmail-FAQ.html fetchmail-features.html \ esrs-design-notes.html +#CONFIGURE_ARGS= --without-hesiod --enable-fallback=no --with-ssl=${OPENSSLBASE} #.include <bsd.port.options.mk> post-patch:
Can you provide additional information on your environment -- freebsd version, options selected for fetchmail, make.conf settings, etc? On 10.3 when built with DEFAULT_VERSIONS+= ssl=openssl in make.conf, I do not see this issue.
(In reply to Corey Halpin from comment #1) Hi Corey, My apologies, I usually provide most of the details required. 1. Env: # uname -aKU FreeBSD hathor 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 r319562M: Mon Jun 5 03:13:08 AEST 2017 root@hathor:/110007/D/K8/hqdev-amd64-smp-vga amd64 1100514 1100514 /usr/ports updated via svnlite on June 6. 2. Build using make. Though I usually use portmaster for a full build. 3. Options: # make -C /usr/ports/mail/fetchmail showconfig |grep =on DOCS=on: Build and/or install documentation GSSAPI_NONE=on: Disable GSSAPI support 4. make.conf is actually a set of 7 different config files, with a lot of loops and if/then conditionals, which basically reduce to: # make -C /usr/ports/mail/fetchmail -VCFLAGS -VSPACER_FOR_READING -VLDFLAGS -O2 -pipe -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UEBUGGING -UDEBUG -march=core2 -mtune=core2 -fstack-protector -fno-strict-aliasing -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector # grep -B2 DEF /etc/make*.conf /etc/make_head.conf:30:DEFAULT_VERSIONS+=perl5=5.24 python=2.7 pgsql=9.6 apache=2.4 gcc=5 samba=4.6 -- /etc/make_head.conf-32-.if ${ARCH} == "i386" /etc/make_head.conf-33-OPENSSL_PORT=security/openssl # To benefit from VIA Padlock /etc/make_head.conf:34:DEFAULT_VERSIONS+=ssl=openssl /etc/make_head.conf-35-.else /etc/make_head.conf-36-OPENSSL_PORT=security/libressl /etc/make_head.conf:37:DEFAULT_VERSIONS+=ssl=libressl The issue arises on both i386 & amd64. 6. If you use gssapi (which is the default) then the absence of ssl via the CONFIGURE_ARGS line is occluded. gssapi requires ssl, and correctly pulls it in. Using gssapi_none reveals the problem; and its little to do with ssl, as that is just a manifestation of the problem. Perhaps if you verify the result of # make -C /usr/ports/mail/fetchmail -VCONFIGURE_ARGS and/or perhaps add something to the Makefile's CONFIGURE_ARGS line to verify that it is being processed correctly. Thanks for looking into the problem. :)
I suspect you're right that the underlying problem here is something in the ports framework to do with GSSAPI_NONE. I'd like to dig into what that is and ideally fix it in the framework so that any other ports that are similarly affected can also benefit from the fix. However, I'm still having trouble replicating the issue. I did discover a separate issue wherein the stage-qa checks introduced in r438176 do not approve of the python shebang line in libexec/fetchmailconf.py when the X11 option is off. I have a patch applied to my local fetchmail to work around it. I need to do more testing to clean up that patch before putting it into a separate PR. For testing this issue, I've created three poudriere sets with the following contents in their make.conf files: /usr/local/etc/poudriere.d/OpenSSL_base_nogss-make.conf: DEFAULT_VERSIONS+= ssl=base OPTIONS_UNSET+= GSSAPI_BASE OPTIONS_SET+= GSSAPI_NONE /usr/local/etc/poudriere.d/OpenSSL_port_no23_nogss-make.conf: DEFAULT_VERSIONS+= ssl=openssl OPTIONS_UNSET+= GSSAPI_BASE OPTIONS_SET+= GSSAPI_NONE security_openssl_UNSET=SSL2 SSL3 /usr/local/etc/poudriere.d/LibreSSL_nogss-make.conf: DEFAULT_VERSIONS+= ssl=libressl OPTIONS_UNSET+= GSSAPI_BASE OPTIONS_SET+= GSSAPI_NONE From what you've provided, it seems like the OpenSSL_port_no23_nogss flavor corresponds to your i386 configuration and the LibreSSL_nogss flavor corresponds to your amd64 configuration. And I've created a script that runs 'poudriere testport' and checks that libssl is linked by the fetchmail binary produced for each of the above flavors on 10.3/i386, 10.3/amd64, 11.0/i386, and 11.0/amd64. In all cases, libssl was linked as expected. I don't currently have an 11.1 environment to test in, but to the best of my knowledge the ports build system should be working similarly on both minor versions of 11.x. Do you see the issue using poudriere on your 11.1 machine when using one of the above *-make.conf files? If so, then I need to spin up an 11.1 environment to work on this further. But if not, it would seem to imply that there's something additional from your environment that I'll need to replicate and further debug the issue. TIA for your assistance in tracking down the problem. The quick and dirty patch I used to make stage-qa happy was as follows: diff -ru fetchmail.old/Makefile fetchmail/Makefile --- fetchmail.old/Makefile 2017-06-18 21:30:14.398717000 -0500 +++ fetchmail/Makefile 2017-06-18 21:30:48.066473000 -0500 @@ -87,10 +87,6 @@ @${MKDIR} ${STAGEDIR}${DOCSDIR} cd ${WRKSRC} && ${INSTALL_DATA} ${PORTDOCS} ${STAGEDIR}${DOCSDIR} -post-install-X11-off: - ${INSTALL_SCRIPT} ${WRKDIR}/fetchmailconf ${STAGEDIR}${PREFIX}/bin - ${INSTALL_SCRIPT} ${WRKSRC}/fetchmailconf.py ${STAGEDIR}${PREFIX}/libexec - .include <bsd.port.pre.mk> .if ${SSL_DEFAULT:Mopenssl-devel} diff -ru fetchmail.old/pkg-plist fetchmail/pkg-plist --- fetchmail.old/pkg-plist 2017-06-18 21:30:14.399774000 -0500 +++ fetchmail/pkg-plist 2017-06-18 21:32:33.947739000 -0500 @@ -1,8 +1,5 @@ bin/fetchmail -bin/fetchmailconf man/man1/fetchmail.1.gz -man/man1/fetchmailconf.1.gz -%%NO_X11%%libexec/fetchmailconf.py %%NLS%%share/locale/ca/LC_MESSAGES/fetchmail.mo %%NLS%%share/locale/cs/LC_MESSAGES/fetchmail.mo %%NLS%%share/locale/da/LC_MESSAGES/fetchmail.mo @@ -27,6 +24,8 @@ %%NLS%%share/locale/tr/LC_MESSAGES/fetchmail.mo %%NLS%%share/locale/vi/LC_MESSAGES/fetchmail.mo %%NLS%%share/locale/zh_CN/LC_MESSAGES/fetchmail.mo +%%X11%%bin/fetchmailconf +%%X11%%man/man1/fetchmailconf.1.gz %%X11%%%%PYTHON_SITELIBDIR%%/fetchmailconf.py %%X11%%%%PYTHON_SITELIBDIR%%/fetchmailconf.pyc %%X11%%%%PYTHON_SITELIBDIR%%/fetchmailconf.pyo
Did this get fixed?
(In reply to Nathan from comment #4) I've not been able to replicate the problem. I just re-ran the poudriere tests described in #3 with 11.2 and 10.4 on both amd64 and i386. In all cases I tested, libssl was properly linked.
Closing per comment #5.