common.o: In function `puts_bidi': /var/tmp/portage/net-mail/mailutils-1.2/work/mailutils-1.2/frm/common.c:173: undefined reference to `fribidi_wcwidth' The ebuild doesn't mention fribidi as a dependency, but the code in that file directly depends on fribidi. It seems that fribidi support is autodetected by the configure script. There is a --without-fribidi switch, so maybe the ebuild should pass $(use_with bidi fribidi) to configure, and add bidi to IUSE of course. fribidi_wcwidth is present in fribidi 0.10.x, but seems to be still missing in 0.19.1. Despite the fact that the fribidi homepage (http://fribidi.org/) states that 0.19.1 "is supposed to be fully API/ABI compatible with the 0.10 series", the TODO file for the 0.19.x series (fribidi2 module) contains an item "Implement fribidi_wcwidth()?" in its "Before release" section. As I assume that different fribidi versions won't be easily installed at the same time, due to conflicting header file locations, slotting fribidi doesn't seem to make a lot of sense. So bidi support in mailutils seems to be mutually exclusive with having fribidi 0.19.x installed. I'll try to patch the mailutils makefile to express this. A quick look at the mailutils git repository indicates that the reference to fribidi_wcwidth is still present in current code, so bumping to mailutils 2.0 as requested by bug #252749 is not going to resolve this issue here.
Created attachment 183878 [details, diff] Changes to mailutils-1.2.ebuild This patch changes the mailutils-1.2 ebuild to handle the bidi USE flag. If enabled, the package will depend on <dev-libs/fribidi-0.19, i.e. I make no assumptions as to what future version will be likely to include fribidi_wcwidth again. Once such a version turns up, the dependency can be changed appropriately.
*** Bug 277589 has been marked as a duplicate of this bug. ***
Thanks for reporting. 2.1 seems to build fine against both old and new fribidi, so I only needed to add USE=bidi to the ebuild without version restrictions.