For the record, recent msys2-runtime path conversions were causing this
error. For example, a simple mingw program that just prints the arguments
would output:
$ ./args.exe ‘ExtUtils::ParseXS::process_file(filename => “$<”,
output => “$@”, typemap => “$(PURPLE_PERL_TOP)/common/typemap”);’
Argument 1 is: ExtUtils;ParseXS;process_file(filename => “$<”, output
=> “$@”, typemap => “$(PURPLE_PERL_TOP)\common\typemap”);
So the perl call in makefile was replacing :: with ; and / with \, leading
to the error. Maybe this affected other build processes too, so if you
started seeing build errors out of nothing recently, Alexey just uploaded a
new msys2-runtime (2.0.16230) with a fix for this.
2014-10-01 15:22 GMT-03:00 Alexpux <[email protected]>:
>
> 01 окт. 2014 г., в 21:04, Renato Silva <[email protected]>
> написал(а):
>
>
> Hi all. I needed to reinstall Windows from scratch. I used to build
> Pidgin++ successfully with MSYS2 before, but not now:
>
>
> make[4]: Entering directory
> '/d/Pidgin/msys2/pidgin.build/libpurple/plugins/perl/common'
> which perl
> /d/Pidgin/msys2/win32-dev/strawberry-perl-5.10.1.5/perl/bin/perl
> perl -MExtUtils::ParseXS -e 'ExtUtils::ParseXS::process_file(filename =>
> "Account.xs", output => "Account.c", typemap =>
> "../../../../libpurple/plugins/perl/common/typemap");'
> Undefined subroutine &main::process_file called at -e line 1.
> ../../../../libpurple/win32/rules.mak:7: recipe for target 'Account.c' failed
> make[4]: *** [Account.c] Error 9
> make[4]: Leaving directory
> '/d/Pidgin/msys2/pidgin.build/libpurple/plugins/perl/common'
>
> I don’t understand why it suddenly started failing, since the build
> environment for Pidgin++ (including the strawberry perl indicated above)
> did not change at all. This error doesn’t happen in MinGW MSYS, no idea
> why. Also, if I just replace strawberry perl with /usr/bin/perl, then it
> builds ok. However this doesn’t make any sense, it should either never have
> worked before, or it should work now too.
>
> I noticed the perl from MSYS2 has a folder ParseXS, not just a single
> file, while strawberry perl only has the single file. But if this was the
> problem, then why the same strawberry perl does work in MinGW MSYS? Is
> ExtUtils::ParseXS being looked up automatically somehow from system’s perl
> (which for some reason fails for MSYS2)? Anyone has any clue about this?
> Thanks in advance.
>
> First, try update packages as I upload new msys2-runtime with some fixes
> for paths translation.
> Second, if you build perl plugin for Pidgin then you always need
> Windows/Mingw version of Perl.
> I don’t recommend use my mingw-perl package.
>
> Msys perl is only for msys programs or just a build tool.
>
> Regards,
> Alexey.
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> Msys2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>
>
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
