Error using pp/PAR wir RPC::XML::Server
Hi all,
I wanted to use 'pp' to build an executable for a little
XML::RPC-Server using module RPC::XML::Server on a linux/debian server.
Unfortunately I get an error, when the running service is going to
execute a service function on request. Let's demonstrate this with a
trivial example:
#!/usr/bin/perl -w
#
use strict;
use warnings;
use RPC::XML::Server;
use IO::Socket::INET;
use constant HOST = '10.0.0.1';
use constant PORT = 33000;
# Create the XML-RPC-server
my $daemon = RPC::XML::Server-new( host = HOST,
port = PORT);
#-
# adding service functions
#-
# Add service function 'helloWorld'
$daemon-add_method({ name = 'helloWorld',
signature = ['string'],
code = \helloWorld });
print \n;
print * \n;
print * Starting Test Service \n;
print * \n;
# Start up the server loop ...
$daemon-server_loop();
#
# Implementation of S E R V I C E F U N C T I O N
#
sub helloWorld {
my $srv = shift;
return Hello World;
}
Let's call this myGeniusService.pl. It provides a function just
returning Hello World on request. I build the executable by using the
'pp' script of the PAR::Packer package:
pp -o myGeniusService myGeniusService.pl
myGeniusService
*
* Starting Test Service
*
When a client requests 'helloWorld', the service terminates with the
following error message:
Can't call method parse on an undefined value at
blib/lib/RPC/XML/Server.pm (autosplit into
blib/lib/auto/RPC/XML/Server/process_request.al) line 1765.
I am surprised about the appearance of _blib_ in the error message.
Does anybody know how to avoid this error message?
Thanks in advance,
Werner
Re: Error using pp/PAR wir RPC::XML::Server
On Mon, May 31, 2010 at 11:14 AM, Developer develo...@onlinehome.de wrote: I wanted to use 'pp' to build an executable for a little XML::RPC-Server using module RPC::XML::Server on a linux/debian server. Unfortunately I get ... Can't call method parse on an undefined value at blib/lib/RPC/XML/Server.pm (autosplit into blib/lib/auto/RPC/XML/Server/process_request.al) line 1765. I am surprised about the appearance of _blib_ in the error message. The blib is a red herring: any autosplit module will report errors in this way (grep for #line statements in any *.al file). IMHO, the real problem is in RPC::XML::ParserFactory. It's used to manufacture the parser used by your instance instance of RPC::XML::Server. ParserFactory is just an interface, it loads one of the RPC::XML::Factory::* implementations which in trun will load a real XML parser module, e.g. XML::LibXML or XML::Parser. My guess is that either RPC::XML::Factory::* or the real XML parsers (or bothe) didn't get included in your packed executable, because Module::Scandeps wasn't able to detect their use by static analysis. In theory, you could try the -x option to pp that would also pack all modules that actually have loaded by your script during execution. However, in your case that's a bit tricky since pp will run your script once for that, so it will probably look hung, because your server script doesn't terminate (unless killed). In addition, it seems that the parser factory is invoked lazily, i.e. only on the first client request, so you would have to run pp -x ... and then start a client from another window. It's probably easier to add RPC::XML::Parser::XMLParser explicitly (it looks like it's the default used by RPC::XML::ParserFactory) with pp -M RPC::XML::Parser::XMLParser ... Cheers, Roderich this should pick up the actual XML::Parser automatically.
Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Sun May 30 08:20:47 2010: Request 57948 was acted upon. Transaction: Correspondence added by mark.doot...@znix.com Queue: PAR-Packer Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll Broken in: (no value) Severity: (no value) Owner: RSCHUPP Requestors: m...@iki.fi Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=57948 Hi, On 29/05/2010 17:55, RSCHUPP via RT wrote: So I see two possible options: - stick with a dynamically linked custom Perl and modify (conditionally for Strawberry only) the whole load_me_* shebang in myldr and add a load_me_3 file that would contain libgcc_s_*.dll (which would get extracted alongside par.exe and perl512.dll) - link the custom Perl statically, then the whole second bootstrap phase is omitted and the problem goes away I definitely don't want to touch the load_me stuff with a ten-foot pole, so I experimented with the latter option. However, even after tweaking myldr/Makefile by hand I couldn't produce a par.exe there that was NOT dynamically linked against perl512.dll. @Mark: Do you know why even g++ main.o my_par_pl.o -Wl,-Bstatic -Lc:\strawberry\perl\lib\CORE -lperl512 -o par.exe generates par.exe with a reference to perl512.dll? Cheers, Roderich I'm not absolutely certain of the total effect of passing -static to ld on windows. For '-lperl512' what matters is what is contained in perl512.lib or libperl512.a. I don't think you can mix and match your linking model on Windows. So if you had a static perl.exe (or par.exe) you could not then load separate xs code dynamically - you would have to compile in all the xs modules you require. That's why, by default, you don't get a static perl built on MSWin. It is not generally useful. In a dynamic perl, all the xs dll's are dynamically linked to perl512.dll. You can't mix and match static / dynamic linking. You have to add a load_me_3 file or some windows specific function that does the same thing, I'm afraid. Regards Mark
