This bug is used for tracking packages broken by perl-core/ExtUtils-ParseXS-3.20.0
Don't CC maintainers when you cannot assign bugs.
I'd like to write a bit here about the way packages are "broken". Seems it's not packages in topic, but gentoo's perl is broken. Consider an example: $ cat a.xs #include "EXTERN.h" #include "perl.h" #include "XSUB.h" MODULE = TestModule PACKAGE = TestModule $ perl /usr/bin/xsubpp -noprototypes a.xs >a.c || echo "FAILED" $ perl /usr/lib/perl5/5.12.4/ExtUtils/xsubpp -noprototypes a.xs >a.c || echo "FAILED" Undefined subroutine &ExtUtils::ParseXS::errors called at /usr/lib/perl5/5.12.4/ExtUtils/xsubpp line 41. FAILED As we see bundled perl's variant is unusable. Some (most of?) packages hardcode perl-relative xsubpp path (as an example xmms2 does in bug #380469): ./wafadmin/Tools/perl.py: conf.env["XSUBPP"] = read_out(" -MConfig -e'print \"$Config{privlib}/ExtUtils/xsubpp$Config{exe_ext}\"'") How do you see this stuff resolved? If we support only xsubpp only in $PATH - fine, I'll patch the package. Thanks!
A note from Florian Ragwitz (perl's and xsubpp's hacker): > [ 00:43:43 < rafl> slyfox: something you might want to add there is that ] > > privlib/xsubpp is in fact the canonical path for xsubpp. the one every > other build system, including ExtUtils::MakeMaker and Module::Build, use. > breaking that will break loads of things.
What's b0rked: - bugs in EU::ParseXS like https://rt.cpan.org/Public/Bug/Display.html?id=70448 causes eg bug 379173 - or https://rt.cpan.org/Public/Bug/Display.html?id=70213 (somehow unconfirmed, why?) is one part of bug 378723 - selfwritten Makefiles using perl -MConfig -e'print "$Config{privlib}/ExtUtils/xsubpp"' (In reply to comment #2) > How do you see this stuff resolved? > If we support only xsubpp only in $PATH - fine, I'll patch the package. (In reply to comment #3) > A note from Florian Ragwitz (perl's and xsubpp's hacker): > > > [ 00:43:43 < rafl> slyfox: something you might want to add there is that ] > > > > privlib/xsubpp is in fact the canonical path for xsubpp. the one every > > other build system, including ExtUtils::MakeMaker and Module::Build, use. > > breaking that will break loads of things. Well, ExtUtils::MakeMaker and Module::Build don't use perl -MConfig -e'print "$Config{privlib}/ExtUtils/xsubpp"' to find xsubpp. They check @INC for the preferred xsubpp. https://metacpan.org/source/MSTROUT/ExtUtils-MakeMaker-6.59/lib/ExtUtils/MM_Unix.pm#L3457 https://metacpan.org/source/DAGOLDEN/Module-Build-0.3800/lib/Module/Build/Base.pm#L5374 That's how the selfwritten Makefiles should find the correct xsubpp. This is also the only way how one could install a newer EU::ParseXS via cpan/cpanm/.. to the site-dir. If they want the privlib/xsubpp useable for all EU::ParseXS versions, then they don't want to change the API(?).
(In reply to comment #4) > What's b0rked: > - selfwritten Makefiles using > perl -MConfig -e'print "$Config{privlib}/ExtUtils/xsubpp"' Ok. I made the package using Module::Build instead: perl -MModule::Build -e'print Module::Build::ModuleInfo->find_module_by_name("ExtUtils::xsubpp")' Does it look better? Thanks!
Out of curiosity could we mask the parser for now until the packages are actualy patched? Since this bug is open for 20 days and still most issues are not fixed you can a) proactively fix the issues so this can be unmasked b) mask the new version that breaks stuff and wait for others to patch it. But please don't keep the tree in semi broken state (i hit this on graphicsmagick and postgres).
I masked it for now as I really don't think we should have such known breakage in ~ tree for long time. Feel free to unmask it when the issues are solved.
Has someone unmasked ExtUtils-ParseXS-3? I can't find it in any package.mask files on my system.
Yes, I did. You can find it in profiles/ChangeLog.
All done here.
