mail-filter/maildrop-2.0.4 fails to find libtoolT?? Reproducible: Always
Created attachment 208696 [details] build.log
config.status: executing libtool commands mv: cannot stat `libtoolT': No such file or directory cp: cannot stat `libtoolT': No such file or directory I see the above several times before the emerge fails. The attached clipped build.log includes more details. (Currently doing a emerge -e world for gcc-4.3.4 upgrade.)
emerge --info please.
That complaint comes from libtool, as it dislikes RM="rm" instead of "rm -f". But the real answer is "this bug is a 2.2.0 stable request". This was fixed here: http://courier.cvs.sourceforge.net/viewvc/courier/courier/maildrop/maildrop/Makefile.am?r1=1.89&r2=1.90 and AFAICT, that went into 2.2.0.
Well now this is even odder. Reran emerge -e --resume, and continued to build a few other applications prior to getting to maildrop and breaking again. This time, it broke at the end of configure, just prior or during the beginning Make. # source /etc/profile && env-update ... then played with some of the eselect modules to make sure any environmental variables were astray. Reran: # FEATURES="ccache distcc" emerge -e --resume world ... and maildrop's configure ran into an endless loop. There's something obviously amiss here. In the process of doing: # FEATURES="-ccache -distcc" MAKEOPTS="-j1" emerge -e --resume world USE="berkdb gdbm ldap mysql -authlib -debug -fam -postgres" for mail-filter/maildrop. maildrop is still in an endless ./configure loop even with -ccache & -distcc. ....mmmmm... .... i'll look at the most recent comment when i get back. .. yes, looks like something else is the culprit besides libtool... but i'm guessing a good clue to what's really going on!
Well, I'd say this bug can be closed as duplicate of bug 290547, especially that it's already marked x86/amd64 stable. And it's hard to reproduce, cause it depends on run order, so ccache/MAKEOPTS change the result.
