Compile and run the following code after install cyrus-sasl2, it would show just "EXTERNAL".
But when using cyrus-sasl 2.1.26 source from ​ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz, it would return the following mechanism. This issue will let the svn client unable to connect to the server with LOGIN/PLAIN authentication mechanism

I just edited the Portfile to change version to 2.1.26, revision to 0, nuked all of the patch files (all of which show as previously applied), and updated the rmd160/sha256 checksums. Then I upgraded. SASL now works. :) Tested with mutt-devel and svn.

It's apparently not as simple as a new Portfile. This break's cyrus-sasl2's binaries because upstream uses a version of libtool 1.3.5. *sobs*

I've gone through and quickly updated libtool in the port the quick and dirty way, but … it's quick and it's dirty. Basically I started with a distclean'd tree and ran glibtool --copy and did everything it told me I ought to do: AC_CONFIG_MACRO_DIR([config]) in configure.in, ACLOCAL_AMFLAGS = -I config in Makefile.am, abd adding several files to aclocal.m4. Didn't see something resembling autogen.sh/bootstrap.sh so I had to do that by hand. I did not generate one patch per file as is the custom because it'd be absolutely nuts to do it.

This "fixes" cyrus-sasl2 as far as port is concerned, but recreates the original bug this ticket is trying to address.

BOOM! A one line patch fixes the 2.1.26 build. I'm not 100% sure this is the most "correct" solution, but it is the most correct solution given the upstream choice to use LD_RUN_PATH as if it contains a single directory. Mutt still works, and so now do the included utilities such as pluginviewer.

[Started looking at this last night, and just finished digging into the cause. It appears there might be a proposed patch, but I'll comment anyway]

Previously, there were /opt/local/lib/sasl2/lib*.la files generated by GNU libtool. However, those files no longer exist (any of them). I have not looked into why.

The plugin mechanism searches the plugin directory for *.la and *.plugin (strcmps around lib/dlopen.c:_sasl_load_plugins:509), but finds neither. With the *.la files, it scans them for /dlname='(.*)'/ to determine the name of the shared library. In my build, LA_SUFFIX=".la" and SO_SUFFIX=".plugin" (lib/dlopen.c).

I copied libplain.la and libsasldb.la from backup, and PLAIN/sasldb started working again.

I am not sure whether this would be a real solution. It is solved in different ways in other distributions. For example, ​Debian patches cyrus-sasl2 to load plugins directly by the *.so name instead of looking for the *.la files.

In 2.1.26_4, shared libs in /opt/local/lib/sasl2 are now named lib*.plugin, and the dlopen code finds and opens them. The PLAIN and SASLDB plugins are working for me (without needing the lib*.la files).

In follow up to response #2: "saslauthd -v" output is unchanged, but I don't know either way what the correct output should be.