PERL="perl" perl /usr/share/perl5/ExtUtils/xsubpp -C++ -typemap /usr/share/perl5/ExtUtils/typemap -typemap typemap.iom -typemap typemap -prototypes ./rxvtperl.xs >rxvtperl.C
perl -MExtUtils::Embed -e xsinit -- -std urxvt
Can't open perl script "/usr/share/perl5/ExtUtils/xsubpp": No such file or directory

This is because of hard-coded wrong path to xsubpp. Please use plain 'xsubpp' which is in PATH.

Fixed by using /usr/bin/xsubpp for now.

This is a bug in fedoras perl or in the fedora urxvt package, not in urxvt. rxvt-unicode upstream does NOT use hardcoded paths but uses the standard location (@PERLPRIVLIBEXP@/ExtUtils/xsubpp) where xsubpp is installed, i.e. it takes the path from the perl configuration - if xsubpp isn't there, then the perl config is broken or the perl package misses the file.

While hardcoding the path in fedoras urxvt package might be a solution that works for fedora (by ensuring xsubpp matches the perl version), it would be better to fix the fedora perl package to actually provide the file in the correct install location, as urxvt is not the only package that requires this file to be present in the correct location. It also gives a dangerous precedent to users of perl, who might think that hardcoding the path to xsubpp is correct, leading to packages that mysteriously fail when users use their own perl installation.

(I am speculating, but maybe this is simply a missing dependency, as fedora might split perl into multiple packages, one of which might have the file, and the other not).

(In reply to redhat-bugzilla from comment #3)
> This is a bug in fedoras perl or in the fedora urxvt package, not in urxvt.
> rxvt-unicode upstream does NOT use hardcoded paths but uses the standard
> location (@PERLPRIVLIBEXP@/ExtUtils/xsubpp) where xsubpp is installed, i.e.
> it takes the path from the perl configuration - if xsubpp isn't there, then
> the perl config is broken or the perl package misses the file.
> 
No. The xsubpp can be stored in any prefix listed in perl's @INC directory. (Users can upgrade the tool independently from the distributor.) To see how it is located by the official ExtUtils::MM_Unix module, study tool_xsubpp() in <http://cpansearch.perl.org/src/BINGOS/ExtUtils-MakeMaker-7.00/lib/ExtUtils/MM_Unix.pm>.

So with your stick-on-upstream mantra, you can implement this silly lookup function into the rxvt-unicode.

Or you can benefit from Fedora which adds a symlink into FHS compliant /usr/bin.

Wow, this is wrong in so many ways.

First, while you can have additional ones, the one that comes with perl is installed in privlibexp, and this is what urxvt is interested in. ExtUtils::MakeMaker is a dual-life module and thus can be installed multiple times (even outside the default path) and has to do extra work. urxvt is not using ExtUtils::MakeMaker, it embeds perl.

Secondly, upgrading it independently will not delete the original version that came with perl, so if its missing, its not missing due to the user, so this explanation doesn't apply.

Thirdly, the FHS says nothing about xsubpp going to /usr/bin or anywhere else, the xsubpp we are talking about here is an internal tool of ExtUtils::MakeMaker.

(stopped counting), perl installs a copy in the binpath (which hopefully is /usr/bin on fedora) for a long time. If fedora replaces it by a symlink that's just another minor incompatibility to upstream perls. Very minor, in fact, but still a needless deviation. Or in other words, its certainly not a benefit of fedora, but something that people might have to work around again (and there is a long history of needless such changes, consider Task::Weaken for example).

Lastly, it's still better to provide the binary in the location where upstream perls install it, rather than hardcoding paths.

If fedora isn't sure about why to make a change, it simply shouldn't do it.

Thank you for your insightfull  view, but Fedora is not Perl upstream. Fedora removes core modules updated by CPAN dual-lived modules due to security and technical (release engineering tools cannot deal with same-named RPM packages) reasons. And this will not change.

well, thanks at least for clarifying that this is a limitation in fedoras toolset, although it is not clear why it couldn't be fixed - perl deals with security updates without having to delete files from an installed perl (which is absolutely necessary because normal users cnanot delete perl base files), so its not clear why fedora couldn't simply rely on that mechanism (other distributions such as debian gnu/linux also do not need to patch their perl/remove files for security updates).

in any case, this vindicates my original point, namely that fedora deviates from upstream, in which case it should also deal with the resulting breakage instead of it leaking into upstream.