The summary and the bug exactly the same as described in #9330 and which was introduced in #9037. To my surprise after being resolved in Samba 3.6 exactly the same problem re-occured in Samba 4.x, now in a different configuration system. In certain system configurations, when port www/libwww is installed a wrong libbrary ${LOCALBASE}/lib/libmd5.so is picked up as an implementation of MD5. Unfortunatelly, it is linked with: U __stack_chk_fail U __stack_chk_guard which isn't properly resolved on runtime. System wide, PROPER library for our luck is named differently, /usr/lib/libmd.so. So, but just swapping checks in the configure the problem is resolved, at least on FreeBSD.
The problem is reported by Stefan Esser <se@freebsd.org>. https://bugzilla.samba.org/show_bug.cgi?id=9330 https://bugzilla.samba.org/show_bug.cgi?id=9037
Created attachment 11381 [details] Fix order of searched libraries for FreeBSD
Patch is also provided by Stefan Esser. My question would be - is it necessary to chase any possible MD5 implementation in the system instead of linking with the bundled MD5 implementation?
Fixed by 03cbef2beff02d54063648725a71be6479886d09 in master for Samba 4.11 We no longer try to link against any system MD5, nor supply our own, we use gnutls consistently.
Glad it's finally got resolved :)