There is an issue with the parameters passed to the configure script for cups. The --enable-pdftops parameter causes the build to make its own pdftops executable. The --with-pdftops parameter is used to specify that an external pdftops executable should be used instead of the one that comes with cups. When both are specified as in the current ebuild, apparently the latter wins out and the configure script will bail out unless a pdftops executable exists on the path. I've included a patch that modifies the way configure is called and corrects the issue. Also, I thought it prudent to preserve the ability to select an external pdftops; I've added a new local USE flag that controls this. The ebuild rev shouldn't need to be bumped as anyone who hasn't encountered this issue (i.e., must have pdftops from another source; several packages appear to provide this executable) need not rebuild cups. - John
Created attachment 206612 [details, diff] Patch to existing ebuild corrects build failure.
Note that cups-1.3.11 and cups-1.4.1 also exhibit this issue. - John
Discovered that this issue was being caused on my machine by a corrupt copy of app-text/poppler-utils. pdftops *should* have been provided by poppler-utils. Closing as INVALID. - John
