Problems with 3rd party libraries and creating modules
Hi, I am currently trying to build a package to access an SAP system ( Inspired by Brian's talk at the German Perl Workshop ) using a third party library supplied by SAP AG. ( http://www.sap.com ) using Inline::C. I have scoured the Inine::C-Cookbook, and there have been many helpfull examples that I have more or less directly plagiarised from inorder to develop a routine that returns a reference to a complex nested hash ( also with nested arrays ). This works just fine in the script context, but when I work it into the package context I end up getting segmentation faults when I, for instance, use Dumper to print out the complex structure. Has anyone got any pointers on what sort of things to specifically look out for when trying to bind third party libraries using Inline -eg. an easily accessable example - that might help me understand what I'm doing wrong? I can supply all the code - but unfortunately unless you have access to an SAP system it is fairly meaning less ( these are the problems with closed source systems :-( ). Thanks. Piers harding.
Re: Has anyone built Inline for HP-UX 11.0?
I have done this but I used the GCC on HP-UX - available from
http://devresource.hp.com. I have had so much trouble with building other products
such as Apache with mod_perl and openssl, and openldap, that I discarded the hp
compiler ( you should see the comments about the hp compiler in the DBD::Oracle help!
).
Cheers.
On Sun, Apr 29, 2001 at 07:18:00PM -0700, Clint Olsen wrote:
Hello:
I tried building 0.32 and some of the tests fail. I am not an expert in
the test harness, so I don't know exactly what is happening and why. I
just downloaded 0.33 and also received some make test errors. I'm using
Perl 5.6.1.
If anyone can tell me what I might be doing wrong, that would be terrific.
-Clint
The C compiler '/opt/ansic/bin/cc' was not found on your system by
searching your PATH. You can install Inline.pm without installing
Inline::C. But you'll need to install another Inline language module
(like Inline::Java for instance) to actually make any use of it.
I don't know why I get this message. Cc is in my path and is:
% which cc
/opt/ansic/bin/cc
% make test
PERL_DL_NONLAZY=1 /afs/pdx/proj/otools/bin/HP-UX/perl -Iblib/arch -Iblib/lib
-I/afs/pdx/proj/otools/perl-5.6.1/lib/5.6.1/PA-RISC2.0
-I/afs/pdx/proj/otools/perl-5.6.1/lib/5.6.1 -e 'use Test::Harness qw(runtests
$verbose); $verbose=0; runtests @ARGV;' t/*.t
t/00initok
t/01usages..ok
t/02config..ok
t/03errors..ok
t/04create..ok
All tests successful.
Files=5, Tests=14, 1 wallclock secs ( 1.06 cusr + 0.25 csys = 1.31 CPU)
PERL_DL_NONLAZY=1 /afs/pdx/proj/otools/bin/HP-UX/perl -I../blib/arch
-I../blib/lib -I/afs/pdx/proj/otools/perl-5.6.1/lib/5.6.1/PA-RISC2.0
-I/afs/pdx/proj/otools/perl-5.6.1/lib/5.6.1 -e 'use Test::Harness qw(runtests
$verbose); $verbose=0; runtests @ARGV;' t/*.t
t/00initok
t/01syntax..Uncaught exception from user code:
Uncaught exception from user code:
A problem was encountered while attempting to compile and install your Inline
C code. The command that failed was:
make out.make 21
The build directory was:
/scratch/Inline-0.33/C/_Inline_test/build/main_C_01syntax_t_6b3a4278c1eae92a7312589d40abe34b/
To debug the problem, cd to the build directory, and inspect the output files.
at t/01syntax.t line 36
Carp::croak('^JA problem was encountered while attempting to compile and
insta...') called at ../blib/lib/Inline/C.pm line 590
Inline::C::compile('Inline::C=HASH(0x401cb654)') called at
../blib/lib/Inline/C.pm line 214
Inline::C::build('Inline::C=HASH(0x401cb654)') called at ../blib/lib/Inline.pm
line 233
Inline::glue('Inline::C=HASH(0x401cb654)') called at ../blib/lib/Inline.pm
line 120
Inline::import('Inline', 'C', '^Jint add(int x, int y) {^Jreturn x +
y;^J}^J^Jint subtract(int x...') called at t/01syntax.t line 36
main::BEGIN() called at t/01syntax.t line 36
eval {...} called at t/01syntax.t line 36
BEGIN failed--compilation aborted at t/01syntax.t line 36.
dubious
Test returned status 9 (wstat 2304, 0x900)
DIED. FAILED tests 1-5
Failed 5/5 tests, 0.00% okay
t/02config..Uncaught exception from user code:
Uncaught exception from user code:
Invalid value './_Inline_test' for config option DIRECTORY
at t/02config.t line 39
Carp::croak('Invalid value \'./_Inline_test\' for config option
DIRECTORY^J^J') called at ../blib/lib/Inline.pm line 321
Inline::check_config('Inline=HASH(0x402d925c)', 'PRINT_INFO', 0, 'WITH',
'ARRAY(0x402d7984)', 'GLOBAL_LOAD', 0, 'DIRECTORY', ...) called at
../blib/lib/Inline.pm line 208
Inline::glue('Inline=HASH(0x402d925c)') called at ../blib/lib/Inline.pm line
120
Inline::import('Inline', 'C', 'char* XYZ_Howdy(){return Hello There;}',
'PREFIX', 'XYZ_') called at t/02config.t line 39
main::BEGIN() called at t/02config.t line 39
eval {...} called at t/02config.t line 39
BEGIN failed--compilation aborted at t/02config.t line 39.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 2-3
Failed 2/3 tests, 33.33% okay
t/03typemap.ok
t/04perlapi.
A problem was encountered while attempting to compile and install your Inline
C code. The command that failed was:
make out.make 21
The build directory was:
/scratch/Inline-0.33/C/_Inline_test/build/main_C_04perlapi_t_3c768e2708cc302ec1fd9ae44421184a/
To debug the problem, cd to the build directory, and inspect the output files.
at t/04perlapi.t line 0
INIT failed--call queue aborted.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Status Wstat Total Fail Failed List of Failed
--
Re: Has anyone built Inline for HP-UX 11.0?
No - all my problems went away when I started using the GCC fro everything :-).
The rarer problems I have now are with some non GCC compiled code, or code that isnt
compiled position independent. Lots of pointers to problems like this on the HP
compiler mailing lists.
Cheers.
On Mon, Apr 30, 2001 at 08:31:47AM -0700, Brian Ingerson wrote:
Piers Harding wrote:
I have done this but I used the GCC on HP-UX - available from
http://devresource.hp.com. I have had so much trouble with building other products
such as Apache with mod_perl and openssl, and openldap, that I discarded the hp
compiler ( you should see the comments about the hp compiler in the DBD::Oracle help!
).
Hmmm. Our tests also used a perl (5.005_03) built with gcc.
$Config::Config{cc} eq 'gcc'
Piers: Did you build perl yourself from the source? You're not mixing a
perl built with HP's compiler, with Inline using gcc. Right?
Clint: If you've got the time, try:
- installing gcc
- put gcc in your path (this will avoid my Makefile.PL bug :)
- build a new perl with gcc
I believe the easiest way to build perl is:
% sh Configure -Dprefix=/base/install/path -ders
% make make test
% make install
, Brian
Re: Has anyone built Inline for HP-UX 11.0?
OK - some more evidence - look on google for pointers towards problems with thread
local storage and HP compilers ( TLS ) - these are also a source of pain for me ( in
particular with linking in the oracle client libraries for instance ).
Cheers.
On Mon, Apr 30, 2001 at 11:18:45AM -0700, Clint Olsen wrote:
Hi Brian:
I built Perl with HP's performance C compiler since I've seen gcc on quite
a few occasions produce considerably slower binaries for the HPPA. We
already have enough performance problems with Perl as it is :) Our system
administrator team built 5.005_03 with this compiler, so I know it's
possible. And Perl 5.6.1 built for me without a hitch whatsoever. It
wasn't until Inline that a wrench was thrown into the works. If I could
see some sort of evidence that this was a compiler problem, I would be more
inclined to revert to gcc... I just don't understand how to analyze this
output when things fail since it appears to be failing in places it
shouldn't...
-Clint
On Apr 30, Brian Ingerson wrote:
Hmmm. Our tests also used a perl (5.005_03) built with gcc.
$Config::Config{cc} eq 'gcc'
Piers: Did you build perl yourself from the source? You're not mixing a
perl built with HP's compiler, with Inline using gcc. Right?
Clint: If you've got the time, try:
- installing gcc
- put gcc in your path (this will avoid my Makefile.PL bug :)
- build a new perl with gcc
I believe the easiest way to build perl is:
% sh Configure -Dprefix=/base/install/path -ders
% make make test
% make install
Re: Has anyone built Inline for HP-UX 11.0?
True - the optional extra ( at a price !) compiler is better than the KR, but I still had problems done the track with building mod_perl into Apache after having built perl cleanly with this. Cheers. On Mon, Apr 30, 2001 at 11:22:29AM -0700, Clint Olsen wrote: Hello: I want to distinguish /opt/ansic/bin/cc from the regular bundled POS compiler in /bin. If it were a choice between /bin/cc or gcc, gcc wins hands down, but the optional compiler is actually quite good. It's just not as footloose and fancy free as gcc. It follows the ANSI standard quite closely, whereas folks using gcc typically don't run gcc with the -ansi switch. -Clint On Apr 30, Piers Harding wrote: I have done this but I used the GCC on HP-UX - available from http://devresource.hp.com. I have had so much trouble with building other products such as Apache with mod_perl and openssl, and openldap, that I discarded the hp compiler ( you should see the comments about the hp compiler in the DBD::Oracle help! ).
Re: Inlining C++ libraries that are threaded and need to callback to perl
Thanks for the reply - I have tried doing direct ( unprotected - no locking ) calls back into the parent interpreter - this barfed badly. 2ndly I have tried the approach of creating separate interpreter instances perthread ( usemultiplicity ) which appears to work fine except that I am still having trouble sorting out the argument stack ( but that is probably ignorance ) - the problem with this is that there is no shared global data across the interpreter instances thus being a bit limiting for a solution. Ideally I would like to have multiple threads calling back into the parent interpreter, so that all the usual concepts of global and shared data are available, but I am unsure as to whether this is possible, and what performance problems this might give if you have to lock each callback. I have tried looking into the code behind the new mod_perl for Apache 2.0 - this is a bit over my head, and is also experimenting with modifications to perl itself ( things called Solar variables ). Cheers. On Sun, Aug 26, 2001 at 02:46:07PM -0400, Sam Tregar wrote: On Sun, 26 Aug 2001, Piers Harding wrote: (1) Wrappering the libraries as a whole is possible - I have done a quick hack, but creating a callback into the perl interpreter from a threaded C++ library is proving very difficult indeed ( well at least it is for me ). Can you describe your difficulties? What approach have you taken? One way you could go would be to treat the Perl interpreter as a non-thread-safe resource and put locks around every access to it. As long as you can be sure that two threads can't access the interpreter at the same time, you should be fine. Alternately, you could build a treading Perl and attempt to create a Perl thread for each C++ thread. Since threads are considered experimental I would probably choose the first option, but I imagine there are reasons you might try the latter. -sam
Re: Inlining C++ libraries that are threaded and need to callback to perl
Well - if anyone is interested - I actually got it working. The key for doing callbacks into the parent perl interpreter was building perl with -Dusemultiplicity. So now I am happily able to have perl - C++ threaded - perl. THanks to those you helped. Cheers. On Sun, Aug 26, 2001 at 04:36:38PM -0400, Sam Tregar wrote: On Sun, 26 Aug 2001, Piers Harding wrote: I have tried doing direct ( unprotected - no locking ) calls back into the parent interpreter - this barfed badly. Yup, that's no good. 2ndly I have tried the approach of creating separate interpreter instances perthread ( usemultiplicity ) which appears to work fine Caution: falling rocks. Some things will work, some things will flatten your car. except that I am still having trouble sorting out the argument stack ( but that is probably ignorance ) This shouldn't be any different than the normal Inline::C case. Maybe you could put together a small test case that demonstrates your problem? Ideally I would like to have multiple threads calling back into the parent interpreter, so that all the usual concepts of global and shared data are available, but I am unsure as to whether this is possible, and what performance problems this might give if you have to lock each callback. This is the path I would recommend. The performance problems will be easy enough to understand - while one callback is executing other callbacks will be blocked. As long as you're careful with what you put in a callback you should be able to manage. I have tried looking into the code behind the new mod_perl for Apache 2.0 - this is a bit over my head, and is also experimenting with modifications to perl itself ( things called Solar variables ). Sounds... experimental. I'd wait for the final product before cutting and pasting. -sam
How do you have multiple Inline .pm's in a Makefile.PL
Hi, I'm trying to publish an Inline based suite that contains several modules in the same directory that have a C++ component, but I can't seem to figure out how to get them into the single Makefile.PL ( and hence Makefile ) to be built. Could someone please tell me how to do this? I have looked through the Inline mail archives and noticed someone else asking this question, but I don't seem to be able to find the answer. Also, it doesn't appear to be mentioned in Inline.pod which does talk about Inline::MakeMaker. Thanks. Piers Harding
Re: How do you have multiple Inline .pm's in a Makefile.PL
talk mode=sheepish My fault - I should have realised /talk Cheers. On Tue, Sep 04, 2001 at 12:09:32AM -0700, Brian Ingerson wrote: On 04/09/01 06:41 +0100, Piers Harding wrote: Sorry if I have offended you in any way... It was not my intention at all, and perhaps - as you suggest below - I may not have looked arround as much as I should have. On Mon, Sep 03, 2001 at 12:54:05PM -0700, Brian Ingerson wrote: to create the module Your::Brain::For::Once::Dude, you could just create Piers, Oops. I'm really sorry if I sounded condescending. I was actually making reference to my latest module YourBrainForOnceDude.pm, which is available on CPAN. (Acme-YBFOD) I guess not everybody's up to date on my modules or stupid sense of humor. Anyway, I try to always be sincerely helpful on this list. Sorry about the misunderstanding. Cheers, Brian
Re: How do you have multiple Inline .pm's in a Makefile.PL
This is brilliant - All I had to do was create a sub directory for each module and make sure the MANIFEST file in the root directory knew about the Makefile.PL in each subdirectory. ./testa ./testa/MANIFEST ./testa/testa.pm - actually test::testa ./testa/Makefile.PL ./testa/test.pl ./testb ./testb/testb.pm - actually test::testb ./testb/Makefile.PL ./testb/MANIFEST ./testb/test.pl ./Makefile.PL ./MANIFEST - knows about all the files in the subdirectories ./test.pl ./test.pm - actually test::test and has reference to test::testa, and test ::testb they all get built into the same lib directory, and can then test together too. The actual name of the sub-directories don't have to have anything to do with the module hierarchy that is held within. This is probably exactly what you meant below - thanks! Great!. Cheers. On Mon, Sep 03, 2001 at 12:54:05PM -0700, Brian Ingerson wrote: On 03/09/01 18:30 +0100, Piers Harding wrote: Hi, I'm trying to publish an Inline based suite that contains several modules in the same directory that have a C++ component, but I can't seem to figure out how to get them into the single Makefile.PL ( and hence Makefile ) to be built. Could someone please tell me how to do this? I have looked through the Inline mail archives and noticed someone else asking this question, but I don't seem to be able to find the answer. Also, it doesn't appear to be mentioned in Inline.pod which does talk about Inline::MakeMaker. Piers, At this point, Inline::MakeMaker assumes that you will have one Makefile.PL and one (Inline-based) module per directory. So the best way to set things up is to have a hierarchy of directories, with one module per. You can build everything from the top level directory. Makefile.PL-s work recursively and Inline::MakeMaker plays along fine. Perl, for better or worse, allows you to create module distributions in many different combinations of ways. You can put many modules in the same directory, you can put hierarchies under a lib/ directory, you can create subdirectories with their own Makefile.PL-s, you can mix these all together. One other way that many people are not aware of is to just define the last node of the module name, and then specify the entire name in the NAME parameter of WriteMakefile. For instance is you wanted to create the module Your::Brain::For::Once::Dude, you could just create a file called Dude.pm at the top level and specify the full name in the Makefile.PL. No need to create all the intervening directories under a lib/ directory. My point is that Inline doesn't support several modules in the same directory, and it doesn't support the lib/ thing yet. But you shouldn't need them. One big advantage to putting each module in a separate subdirectory is that you can have README, Changes, etc files for that module. Hope that helps. Let me know if you get stuck. If so, be sure to forward all details. Cheers, Brian
Installable CPP based Inline modules
Hello, Are ther any plans to make CPP modules installable like C? I am in the process of publishing a set of modules based on Inline::CPP, and I'm trying to figure out what options I have for delivering them. Thanks, Piers harding
Essay: using Inline - perl 2 c++ 2 perl 2 c++
Hello Everybody, As a result of my painful learning experiences of embedding C++ in perl, and then doing various nested callbacks, I have written a small essay on the topic, with a full ( 1 file based ) example. For those that are interested, please go to http://www.ompa.net/perl2c2perl2c.html, and for other Inline and Jabber related stuff http://www.pipetree.com/jabber/. Cheers.
Re: Inline and the 5.6.0 that comes with OS X
How would Inline/Module::Build take care of ( in a platform independent way ) processes like moving files, copying etc. Would it still use the ExtUtils::Command routines for this? It is dealing with these kinds of issues that are also dealt with in make that need to be overcome. Would there be any benefit in producing a quick bunch of basic build tests that we could run on a variety of platforms to determine if this kind of approach is going to pay off. I can help with that if it seems like a good idea? What kinds of platforms do people on the list have at their disposal for testing out these issues? Cheers. On Sun, Aug 18, 2002 at 02:31:52PM +1000, Ken Williams wrote: On Saturday, August 17, 2002, at 08:23 AM, Nicholas Clark wrote: Inline only uses MakeMaker to compile 1 XS file into 1 C file into 1 shared object, doesn't it? It's not using most of MakeMaker's functionality. This is the same subset of MakeMaker's functionality that is currently supported by Module::Build, too. The main reason Module::Build hasn't gone further is that I don't yet understand the other scenarios that need to be supported. I can see basically what MakeMaker is capable of from its documentation, but I don't yet know how it's used in practice in CPAN modules. Invoking the compiler in a more direct fashion would also avoid make. So it would allow much better error diagnostics. Yeah, this is the approach Module::Build takes. There's a compile_c() method and a link_c() method, which invoke C compilers by calling the do_system() method, which just calls CORE::system(). The compilation commands are just pieced together from pieces of the %Config hash. I've been surprised at how successful that's been, actually. Then, on Saturday, August 17, 2002, at 04:29 PM, Brian Ingerson wrote: I've removed the dependency of Parse::RecDescent thanks to a great patch from Mitchell Charity that does the job with regexps. It'd be a shame to add a new dependency. If you don't want another dependency for Inline itself, you could certainly copy the compile_c() and link_c() methods from Module::Build. They're fairly simple. It would be nice to share some code, though, for the reasons Nick outlined. It would be cool to distribute M::B within Inline and also within the modules that require Inline. This doesn't really help, I think. It's not that people are too lazy to download the prerequisites, it's that they don't want the conceptual complexity of a larger (and seemingly unnecessary - see below) web of installed prerequisites on their system. The ultimate goal being that you want authors to be able to use Inline instead of XS without it imposing any dependencies on their work. I think this is one thing that keeps people from writing serious modules with Inline. I think that if Inline were truly a build-time-only dependency for modules (without even the small run-time stub you've been thinking of), that would help quite a bit. I don't think people care so much about startup performance as they do keeping track of prerequisites. Module::Build introduces the concept of build_requires vs. requires, maybe this would help. If Inline weren't a run-time dependency, then, you could feel free to have Inline depend on whatever you wanted. You wouldn't be saddling people's modules with more dependencies. -Ken
Re: Inline and the 5.6.0 that comes with OS X
Cool.
Brian did talk about wanting to remove make from the build process - he
was probably refering to his conversations with you. I must admit that
I didn't think it was a good idea at the time, but perhaps it would work
if there is sufficient other ways ( that are part of the core ) to get
rid of the OS specific parst that make and MakeMaker deals with.
Another question - is it possible to get the Build.PL file to
sufficiently emulate a Makefile.PL file so that -
(a) if someone doesn't have Module::Build they get informed of it
and
(b) CPAN.pm can work with it? ie. rename the Build.PL to Makefile.PL -
and it just works. That might be a goal to aim for, as people who are
not familiar/interested in module build processes use tools like CPAN.pm
and ppms.
I have Linux, and HP-UX, Windows ( of all sorts of nasty flavours ;-),
and maybe some more via Melbourne.pm if I can ask them the favour.
Cheers.
On Sun, Aug 18, 2002 at 07:15:55PM +1000, Ken Williams wrote:
[Adding the Module::Build list to recipient list, and getting
rid of Mac OS X...]
On Sunday, August 18, 2002, at 06:11 PM, Piers Harding wrote:
How would Inline/Module::Build take care of ( in a platform independent
way ) processes like moving files, copying etc. Would it still use the
ExtUtils::Command routines for this?
In general Module::Build uses lots of ExtUtils::* or File::*
routines. I haven't yet seen the need for ExtUtils::Command in
Module::Build, because most of the things supported there either
have equivalents in File::* or in core perl.
It is dealing with these kinds of issues that are also dealt
with in make that need to be overcome. Would there be any
benefit in producing a quick bunch of basic build tests that we
could run on a variety of platforms to determine if this kind
of approach is going to pay off. I can help with that if it
seems like a good idea?
Yes, these kinds of tests can simply become part of the
regression test suite for Module::Build. It would be great to
add to its existing tests.
What kinds of platforms do people on the list have at their
disposal for testing out these issues?
I only have Mac OS X (perl 5.6.1) at my immediate disposal,
though I can test on Linux (perl 5.6.1) from time to time.
In general, eliminating 'make' and using the ExtUtils::* and
File::* modules seem to be doing a really good job of allowing a
single code base with no if ($platform eq _something_) {
statements in Module::Build.
-Ken
On Sun, Aug 18, 2002 at 02:31:52PM +1000, Ken Williams wrote:
On Saturday, August 17, 2002, at 08:23 AM, Nicholas Clark wrote:
Inline only uses MakeMaker to compile 1 XS file into 1 C file
into 1 shared
object, doesn't it? It's not using most of MakeMaker's functionality.
This is the same subset of MakeMaker's functionality that is
currently supported by Module::Build, too.
The main reason Module::Build hasn't gone further is that I
don't yet understand the other scenarios that need to be
supported. I can see basically what MakeMaker is capable of
from its documentation, but I don't yet know how it's used in
practice in CPAN modules.
Invoking the compiler in a more direct fashion would also avoid make.
So it would allow much better error diagnostics.
Yeah, this is the approach Module::Build takes. There's a
compile_c() method and a link_c() method, which invoke C
compilers by calling the do_system() method, which just calls
CORE::system(). The compilation commands are just pieced
together from pieces of the %Config hash. I've been surprised
at how successful that's been, actually.
Then, on Saturday, August 17, 2002, at 04:29 PM, Brian Ingerson wrote:
I've removed the dependency of Parse::RecDescent thanks to a
great patch from
Mitchell Charity that does the job with regexps. It'd be a
shame to add a new
dependency.
If you don't want another dependency for Inline itself, you
could certainly copy the compile_c() and link_c() methods from
Module::Build. They're fairly simple. It would be nice to
share some code, though, for the reasons Nick outlined.
It would be cool to distribute M::B within Inline and also within
the modules that require Inline.
This doesn't really help, I think. It's not that people are too
lazy to download the prerequisites, it's that they don't want
the conceptual complexity of a larger (and seemingly
unnecessary - see below) web of installed prerequisites on their
system.
The ultimate goal being that you want
authors to be able to use Inline instead of XS without it
imposing any
dependencies on their work. I think this is one thing that
keeps people from
writing serious modules with Inline.
I think that if Inline were truly a build-time-only dependency
for modules (without even the small run-time stub you've been
thinking of), that would help quite a bit. I don't think
Re: Simple Inline C Problem.
Try it like this:
use Inline C;
greet();
__END__
__C__
void greet() {
printf(Hello, world\n);
}
Cheers.
On Tue, Aug 27, 2002 at 11:12:53AM -0700, Yimeng Dou wrote:
I have this very simple inline C code, but somehow
it doesn't work.
I receive INIT failed--call queue aborted. when I run it.
Here is the code, please help. Thanks!
use Inline C;
__END__
__C__
void greet() {
printf(Hello, world\n);
}
greet;
-
Yimeng Dou
[EMAIL PROTECTED]
Department of Information and Computer Science
University of California, Irvine
Re: Simple Inline C Problem.
OK.
What are you running this on. The code I gave you was run under Linux
RH7.3 + perl 5.6.1 + Inline 0.43.
you could also trygiving us some of the output from the _Inline
directory ( located from where you are running that script ).
CHeers.
On Tue, Aug 27, 2002 at 07:43:21PM +0100, Piers Harding wrote:
Try it like this:
use Inline C;
greet();
__END__
__C__
void greet() {
printf(Hello, world\n);
}
Cheers.
On Tue, Aug 27, 2002 at 11:12:53AM -0700, Yimeng Dou wrote:
I have this very simple inline C code, but somehow
it doesn't work.
I receive INIT failed--call queue aborted. when I run it.
Here is the code, please help. Thanks!
use Inline C;
__END__
__C__
void greet() {
printf(Hello, world\n);
}
greet;
-
Yimeng Dou
[EMAIL PROTECTED]
Department of Information and Computer Science
University of California, Irvine
Re: Simple Inline C Problem.
From the look of it - the code compiled ok on your system but your
linker is squealing like a stuck pig :-). I don't know that much about
Win32 compiling systems, but you need to find some info ( maybe from
www.activestate.com ) about what compilers/linkers you should be using.
CHeers.
On Tue, Aug 27, 2002 at 06:44:38PM -0700, Yimeng Dou wrote:
Hi,
Here is the C code, and the out.make file in the build directory.
/*
* This file was generated automatically by xsubpp version 1.9508 from the
* contents of try_pl_419e.xs. Do not edit this file, edit try_pl_419e.xs
instead.
*
*ANY CHANGES MADE HERE WILL BE LOST!
*
*/
#line 1 try_pl_419e.xs
#include EXTERN.h
#include perl.h
#include XSUB.h
#include INLINE.h
void greet() {
printf(Hello, world\n);
}
#line 18 try_pl_419e.c
XS(XS_main_greet)
{
dXSARGS;
if (items != 0)
Perl_croak(aTHX_ Usage: main::greet());
SP -= items;
{
#line 16 try_pl_419e.xs
I32* temp;
#line 28 try_pl_419e.c
#line 18 try_pl_419e.xs
temp = PL_markstack_ptr++;
greet();
if (PL_markstack_ptr != temp) {
/* truly void, because dXSARGS not invoked */
PL_markstack_ptr = temp;
XSRETURN_EMPTY; /* return empty stack */
}
/* must have used dXSARGS; list context implied */
return; /* assume stack size is correct */
#line 39 try_pl_419e.c
PUTBACK;
return;
}
}
#ifdef __cplusplus
extern C
#endif
XS(boot_try_pl_419e)
{
dXSARGS;
char* file = __FILE__;
XS_VERSION_BOOTCHECK ;
newXS(main::greet, XS_main_greet, file);
XSRETURN_YES;
}
=
out.make file:
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib
C:\Perl\lib\ExtUtils/xsubpp -typemap C:\Perl\lib/ExtUtils/typemap
try_pl_419e.xs try_pl_419e.xsc
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib -MExtUtils::Command -e mv
try_pl_419e.xsc try_pl_419e.c
cl -c -IC:/Perl/examples -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_ST
RICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MS
VCRT_READFIX -O1 -MD -DNDEBUG-DVERSION=\0.00\ -DXS_VERSION=\0.00\
-IC:\Perl\lib\CORE try_pl_419e.c
try_pl_419e.c
Running Mkbootstrap for try_pl_419e ()
C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib -MExtUtils::Command -e
chmod 644 try_pl_419e.bs
C:\Perl\bin\perl.exe -IC:\Perl\lib
-IC:\Perl\lib -MExtUtils::Mksymlists -e Mksymlists('NAME' =
'try_pl_419e', 'DLBASE' = 'try_pl_419e', 'DL_FUNCS' = { }, 'FUNCLIST' =
[], 'IMPORTS' = { }, 'DL_VARS' = []);
link -out:blib\arch\auto\try_pl_419e\try_pl_419e.dll -dll -nologo -nodefault
lib -release -libpath:C:/Perl\lib\CORE -machine:x86 try_pl_419e.obj
C:\Perl\lib\CORE\perl56.lib oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib
odbccp32.lib msvcrt.lib -def:try_pl_419e.def
OPTLINK (R) for Win32 Release 7.50.6
Copyright (C) Symantec Corporation 1989-97 All rights reserved.
OPTLINK : Warning 9: Unknown Option : OUT
OPTLINK : Warning 9: Unknown Option : DLL
OPTLINK : Warning 9: Unknown Option : RELEASE
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : PERL\LIB\CORE
:blib\arch\auto\try_pl_419e\try_pl_419e.dll
Error 2: File Not Found :blib\arch\auto\try_pl_419e\try_pl_419e.dll
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.
-Original Message-
From: Piers Harding [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 12:59 PM
To: Piers Harding
Cc: Yimeng Dou; [EMAIL PROTECTED]
Subject: Re: Simple Inline C Problem.
OK.
What are you running this on. The code I gave you was run under Linux
RH7.3 + perl 5.6.1 + Inline 0.43.
you could also trygiving us some of the output from the _Inline
directory ( located from where you are running that script ).
CHeers.
On Tue, Aug 27, 2002 at 07:43:21PM +0100, Piers Harding wrote:
Try it like this:
use Inline C;
greet();
__END__
__C__
void greet() {
printf(Hello, world\n);
}
Cheers.
On Tue, Aug 27, 2002 at 11:12:53AM -0700, Yimeng Dou wrote:
I have this very simple inline C code, but somehow
it doesn't work.
I receive INIT failed--call queue aborted. when I run it.
Here is the code, please help. Thanks!
use Inline C;
__END__
__C__
void greet() {
printf(Hello, world\n);
}
greet;
-
Yimeng Dou
[EMAIL PROTECTED]
Department of Information and Computer Science
University of California, Irvine
Re: Patch for Inline::C-Cookbook
Perl is full of surprises :-) - I'd never heard of it too, or perlapio ( pointed to herein ) *sigh* so little time so much to learn Cheers. On Tue, Sep 03, 2002 at 12:09:05PM +1000, Ken Williams wrote: On Monday, September 2, 2002, at 06:41 PM, Neil Watkiss wrote: Hi Ken, You shouldn't mix this: soldier-name = strdup(name); with this: Safefree(soldier-name); because strdup() is just a C library function that uses malloc(), and Safefree might not be. You want to use savepv(), which is the Perl API's equivalent that's guaranteed to work with Safefree. Have a look at 'perldoc perlapi' for more info. Wow, I'd never have known that from `perldoc perlapi`. I had to look at `perldoc perlclib`, which I'd never even *heard* of before, and which I'd never have found without `grep savepv /usr/share/man/man1/perl*`. I'll be changing this in my own code now too. Thanks for the pointer. -Ken
Re: About Inline 0.50
Nadim - you are polluting this ML with your insensitive comments. No one around here wants that kind of counter productive input. What part of Open Source don't you get? All of us here are volunteers of some kind or another, so we don't appreciate being told what to do, and how to act with our freely given time. I suggest you either reassess your approach, or you will quickly find things will get even more frustrating for you, until you finally understand what makes THIS world go round. Hey - perhaps you should try being cute and nice once in a while - you might even like it. Cheers. On Sat, Oct 05, 2002 at 12:24:03AM +0200, nadim wrote: Hi all I think it's time to set the clocks so we stop arguing about nothing. My general feeling first then some precise answers. On Friday 04 October 2002 19:50, Piers Harding wrote: So Brian - +1 from me, and keep up the good work. On Friday 04 October 2002 20:52, Patrick LeBoutillier wrote: So another +1 for Brian. Both of you are cute and nice and since you mean well I am _not_ going to start a stupid war with you or whoever. Before I send my first mail to the list I did send a copy to Brian and Asked him if it was OK to mail this to the list, which he agreed to without asking me to rephrase it. You can ask him in a private mail. By the way that's what you should have done with your reactions, send them to me instead of polluting the ML with you pluses. Whatmore Brian can and has answered the points I suggested so let's continue working towards solutions as Brian did. I belive The way Inline is run could be better. period. I believe that Inline should not only depend on the availability, or lust of Brian or yours or mine. This is a technical question so let's keep at the technial level. I for one am perfectly happy to follow Brians' lead on where and how he wants to go forward with Inline. Good and you count as one, as I do. I have suggestion (that you must respect). If they go through fine, if not fine. This is just a piece of software, I am not loosing my cool over it. As for the undertones regarding writing a book, and the commercial interest there in - I can vouch for the fact that I'm sure that Brian is doing it for the love portion, as there will be bugger all money in it. Give me a break, I don't care who earns money and how much and when.I have good pay and if Brian or you can earn money on a book, fine. Brian writes that there is a schedule and I can ask ORA. ORA schedule is for the book not for Inline, except if they are using it to write programs. What is wrong with that? I don't use undertones. I either don't care or make myself understood because I am not subtile enougth for undertones. I'm sure that following some of your suggestions could lead to more frequent Inline releases So let start working on them.Also, my concern has nothing to do with release frequency (even if small release on short schedule is better), It's about how things are run. What suggestions did you like and which ones did you dislike and why? Let's get this stuff running fast. - That would make Brian a manager, having to coordinate other people's work, leaving with no less time to do some coding of his own. Maybe that's not what he wants to do. ah, finally something to construct upon. The answer to this is: No I don't ask brian to become manager I ask him to open the devlopment so we have a more efficient way of getting Inline better. Maybe we could share the burden in a more efficient way so Brian gets more time for coding or gardening if he likes to. - Maybe if you went about presenting your ideas in a more diplomatic fashion you would get more people interested in what you have to say. pick one of the following: 1/ I don't have time to baby sit you. I sit in front of my computer not at united nations. 2/ Yes, you are right, I could be more diplomatic. If anyone has personal griefs against me, we can take it privately to not bother the rest of the ML. Now if you guys could take another round and re-read my mails and point out what you like and dislike and why (keeping in mind that I mean well) and keep it at the engineering level, I'll be glad to work things out with you because I, too, like Inline and want to see it grow. I am already quite satisfied, The Wiki idea a very good starting point. weather Brian did it because of my undiplomatic suggestions or because he just wanted to do it or because he wanted me to stfu doesn't change a thing. Nadim.
Re: out.make
It might be worth thinking about giving varying degrees of the output depending on command line options, or CONFIG directives. For me - 9/10 times the error tracks back to things like actual C code/XS problems, or some kind of issue arround gcc directives like INC or LIB pathes - maybe there would be a good way of representing this kind of info. Also - it would be still nice to retain the error info that you allready print out, as this shows where it did the build this time. Cheers. On Sun, Oct 06, 2002 at 07:19:10AM -0700, Brian Ingerson wrote: On 06/10/02 19:13 +1000, Sisyphus wrote: Guys, While improvements to Inline are being discussed, is there any chance of having the contents of out.make tee'd to stdout ? Yes! This is a great idea. Shouldn't it go to stderr? And are there any other files that need to get dumped? Any other ideas of what to do here? I think this would be one of the lowest hanging fruit. I've just never been sure of exactly what to do. Cheers, Brian
Re: Inline-0.44-TRIAL4.tar.gz -- CPPTest.pm installation problem
Thanks. I'll look into developing some tests. How do we want to build up a test suite - as the dependency is on an ILSM not on Inline perse? CHeers. On Tue, Oct 15, 2002 at 06:51:42PM -0400, Mitchell N Charity wrote: I've got a problem with this one for the Installable CPP module: [...] Where do I start looking? It looks like the my dirparts = (grep($_, File::Spec-splitdir($dir)), $file); line in Inline.pm. Here is a patch backward from TRIAL4 to an earlier version of Brian's code (he was planning on backing out the grep, but I guess it didn't make TRAIL4). $ cd Inline-0.44-TRIAL4 $ patch attached_patch The patched version make test's ok, and works on your example. I've not exercised it beyond that. I've taken the liberty of also rolling back the $dirparts[-1] test, which was another change that worried me. Looks like some module installation test cases are needed. Volunteers? Mitchell == --- Inline.pm Tue Oct 15 18:17:56 2002 +++ Inline.pm.new Tue Oct 15 18:17:44 2002 -432,10 +432,12 or croak M27_module_not_indexed($realname); my ($volume,$dir,$file) = File::Spec-splitpath($realpath); -my dirparts = (grep($_, File::Spec-splitdir($dir)), $file); +my dirparts = File::Spec-splitdir($dir); +pop dirparts unless $dirparts[-1]; +push dirparts, $file; my endparts = splice(dirparts, 0 - pkgparts); - -$dirparts[-1] = 'arch' if dirparts[-2, -1] eq 'blib lib'; +$dirparts[-1] = 'arch' + if $dirparts[-2] eq 'blib' $dirparts[-1] eq 'lib'; File::Spec-catfile(endparts) eq $realname or croak M28_error_grokking_path($realpath); $realpath = ==
ANNOUNCE: Inline::BC (VERSION 0.01)
Announcing Inline::BC Version 0.01, a new ILSM for the Gnu bc arbitrary precision maths language (man bc, or http://www.gnu.org/software/bc/bc.html). This is winging it's way to CPAN as I speak, and should be at a mirror near you, soon :-). Cheers.
Re: Inline-0.44-TRIAL5
My tests (CPP) work fine. Cheers. On Fri, Oct 18, 2002 at 01:16:51AM -0700, Brian Ingerson wrote: http://ttul.org/~ingy/release/Inline-0.44-TRIAL5.tar.gz --- version: 0.44 date:Thu Oct 17 20:00:46 PDT 2002 changes: - Shortened BUILD_TIMER precision, per Leon Brocard's suggestion. - Applied Mitchell Charity's patch to fix Piers Harding's CPP problem. - Fixed bug with USING keyword The features for 0.44 are complete. Just bug fixes and doc updates will go in now. Cheers, Brian
Re: Inline-0.44-RELEASE-CANDIDATE-1
Works fine for me :-). On Thu, Oct 24, 2002 at 09:24:39PM -0700, Brian Ingerson wrote: http://ttul.org/~ingy/release/Inline-0.44-RELEASE-CANDIDATE-1.tar.gz All bugs reported since TRIAL8 have been fixed. I did a bunch of work on ParseRecDescent and added more regression tests. ParseRegExp already did everything correctly. (Tell me why we don't make it the default?) Actually in 0.50, ParseRegExp will be the default for sure. BTW, I'm on the 0.50 warpath again. I did a lot of coding on it yesterday. It's actually pretty far along. I may even have a trial of 0.50 before 0.44 ships! Cheers, Brian Keep banging on 0.44 :)
Re: Using Inline.pm from an embedded perl interpreter.
I presented on this at OSCON - there are a whole bunch of things to think about when calling back and forth. Have a look at http://www.piersharding.com/tydwp/tydwp.dkb Cheers. On Tue, Oct 29, 2002 at 06:53:25PM -0800, Brian Ingerson wrote: On 30/10/02 02:28 +, Christian Goetze wrote: Apologies if this is not the best address - please feel free to forward this to the appropriate forum. I am trying to use Inline from within an embedded perl interpreter. The problem I'm running into is that any method defined as a C function will not cause the .so to be loaded, giving me this type of error: Can't locate object method new via package Yax (perhaps you forgot to load Yax?) The exact same code will run fine when run from a standalone perl script. Do you know of any fundamental limitations when running from an embedded perl interpreter linked in via libperl.a? Thanks in advance - and great work on a potentially extremely useful module!!! Hrm. What happens when you build a new XS module from CPAN? Does it get linked into libperl.a? This might be problematic for Inline. If you could tell me how to build a static Perl I could look into it myself. I haven't played much in this realm. I don't recall whether inline forces a dynamic build. I'm cc'ing [EMAIL PROTECTED] mailing list. Let's keep the thread going there. Neil Watkiss will probably know the answer :) Cheers, Brian
Re: Using Inline.pm from an embedded perl interpreter.
Sounds like it is running into the either the Taint checking issue or
Inline is not bootstraping the module.
You could try something like:
require DynaLoader;
eval { DynaLoader::bootstrap(Yax) };
inside your module to make sure this is happening?
Cheers.
On Thu, Oct 31, 2002 at 01:59:53AM +, Christian Goetze wrote:
Did you try writing it as an Inline *module* (like Math::Simple in the
distro)?
If with that you mean using this:
use Inline::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteInlineMakefile(
'NAME' = 'Yax',
'VERSION_FROM' = 'Yax.pm', # finds $VERSION
'PREREQ_PM' = {}, # e.g., Module::Name = 1.1
);
and this:
package Yax;
require 5.005_62;
use strict;
use warnings;
use vars qw($VERSION ISA EXPORT);
require Exporter;
ISA = qw(Exporter);
EXPORT = qw(); # doesn't seem to be necessary
$VERSION = '0.20';
use Inline (C = 'DATA',
NAME = 'Yax',
VERSION = '0.20',
MYEXTLIB = '/home/cg/Yax/libyax.a',
);
1;
__DATA__
Then yes, we did build a module. It installed a Yax.so into site_perl and
everything you'd expect.
Running the embedded perl with strace showed that no attempt was made to
load Yax.so, so I'm assuming something is wrong with the loader logic...
--
cg
Re: Default Inline::C includes
Does AUTO_INCLUDE work for C ( like CPP )?
'Config' =
'AUTO_INCLUDE' = [ undef,
myheader.h,
...
]
Cheers.
On Tue, Nov 12, 2002 at 05:19:54PM -0500, Patrick LeBoutillier wrote:
Hi all,
I'm writing a simple Inline wrapper to the rpmVersionCompare
function from librpm. The way the rpm headers are made (rpm 4.0.2-8),
I can't compile if I do:
#include EXTERN.h
#include perl.h
#include XSUB.h
#include INLINE.h
#include rpm/rpmlib.h
I have to do:
#include rpm/rpmlib.h
#include EXTERN.h
#include perl.h
#include XSUB.h
#include INLINE.h
Is there a way to suppress these 4 default header lines in Inline::C or
insert my own headers in front?
I can get around it like this, but it's not really elegant:
#!/usr/bin/perl
use strict ;
BEGIN {
require Inline::C ;
*Inline::C::validate_ori = \Inline::C::validate ;
*Inline::C::validate = sub {
my $o = shift ;
$o-{ILSM}{AUTO_INCLUDE} = /*\n ;
Inline::C::validate_ori($o, _) ;
} ;
}
use Inline (
C = 'DATA',
LIBS = '-lrpm -lrpmio -lpopt',
INC = '-I/usr/include/rpm',
AUTO_INCLUDE = */,
) ;
sub rpmVersionCompare {
my $fv1 = shift ;
my $fv2 = shift ;
my ($v1, $r1) = split(/-/, $fv1) ;
my ($v2, $r2) = split(/-/, $fv2) ;
return __rpmVersionCompare(
$v1 || , $r1 || ,
$v2 || , $r2 || ,
) ;
}
my $v1 = 1.3.23-4 ;
my $v2 = 1.3.9-7 ;
print $v1 $v2 ? . rpmVersionCompare($v1, $v2) . \n ;
__END__
__C__
#include rpm/rpmlib.h
#include EXTERN.h
#include perl.h
#include XSUB.h
#include INLINE.h
int __rpmVersionCompare(char *v1, char *r1, char *v2, char *r2){
Header h1 = headerNew() ;
Header h2 = headerNew() ;
headerAddEntry(h1, RPMTAG_VERSION, RPM_CHAR_TYPE, v1, strlen(v1)) ;
headerAddEntry(h1, RPMTAG_RELEASE, RPM_CHAR_TYPE, r1, strlen(r1)) ;
headerAddEntry(h2, RPMTAG_VERSION, RPM_CHAR_TYPE, v2, strlen(v2)) ;
headerAddEntry(h2, RPMTAG_RELEASE, RPM_CHAR_TYPE, r2, strlen(r2)) ;
return rpmVersionCompare(h1, h2) ;
}
Thanks,
Patrick
-
Patrick LeBoutillier
Laval, Quebec, Canada
Re: sort() function
You could potentially emulate the Perl way using the macros and
functions.
See the perlapi (perldoc) for:
sortsv - to do the sort (doh!)
hv_iterkeysv - to grab the keys, and av_push to build the array for
sorting.
# warning - example stolen from tt2 code
AV *result = newAV();
HE *he;
hv_iterinit(hash);
while ((he = hv_iternext(hash))) {
av_push(result, SvREFCNT_inc((SV *) hv_iterkeysv(he)));
}
sortsv(AvARRAY(result), av_len(result)+1, Perl_sv_cmp_locale);
Or something similar (there are other sorts in pp_sort.c I think).
Cheers.
On Mon, Mar 07, 2005 at 01:13:24PM -0500, [EMAIL PROTECTED] wrote:
Hi Guys
I am re-implementing a perl subroutine in C and this perl-subroutine
sorts the key of a hash given to it as input before using it. This hash
usually hold about 3000-4000 keys. So I am wondering what to do here:
1) Create another hash in perl-space and sort its keys using the perl
sort() function and then pass that hash as input
2) Write my own sort function or, even better, use one from a better
source like the Gnu Scientific Library or another third party library.
So, what I am basically asking is if it is worth replaceing perl's sort
function with another one in inlined space or not ?
Thanks !
Nitin
--
http://www.piersharding.com
http://search.cpan.org/~piers/
Re: Inline::CPP problem = Virtual destructors and Editor::Copy()
Hi,
I have just tried this under Perl 5.8.5, and renamed Copy to xCopy,
which has compiled cleanly.
Further - I had to change $e-cut to $e-Cut.
Cheers,
Piers Harding.
On Mon, Mar 21, 2005 at 03:36:00PM +0100, Subir Sarkar wrote:
Hi all,
I'm trying to use a C++ library from Perl using Inline::CPP. The
problems I've found so far
can be reproduced with the simple program below.
1. virtual destructor is not supported
2. The Editor::Copy() method clashes with some other from the Perl
library (handy.h?)
Thank you for any help.
- Subir
---
use Inline CPP;
my $e = new Editor;
$e-cut;
__END__
__CPP__
class Editor {
public:
Editor() {}
~Editor() {} // Does not seem to support virtual destructor
virtual void Print();
virtual void Cut();
virtual void Copy(); // handy.h has another Copy()
virtual void Paste();
};
void Editor::Print() {
cout Object ( this ) endl;
}
void Editor::Cut() {
cout Cut text endl;
}
void Editor::Copy() {
cout Copy text to buffer endl;
}
void Editor::Paste() {
cout Paste text from buffer endl;
}
pcsarkar [392] perl -w Editor.pl
/usr/bin/perl /usr/lib/perl5/5.8.5/ExtUtils/xsubpp -typemap
/usr/lib/perl5/5.8.5/ExtUtils/typemap -typemap
/home/sarkar/Perl/root_examples/_Inline/build/Editor_pl_b8fe/CPP.map
Editor_pl_b8fe.xs Editor_pl_b8fe.xsc mv Editor_pl_b8fe.xsc
Editor_pl_b8fe.c
g++ -c -I/home/sarkar/Perl/root_examples/ -D_REENTRANT -D_GNU_SOURCE
-DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686
-DVERSION=\0.00\ -DXS_VERSION=\0.00\ -fPIC
-I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE Editor_pl_b8fe.c
In file included from /usr/include/c++/3.2.3/backward/iostream.h:31,
from Editor_pl_b8fe.xs:2:
/usr/include/c++/3.2.3/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the X
header for the X.h header for C++ includes, or sstream instead of
the deprecated header strstream.h. To disable this warning use
-Wno-deprecated.
Editor_pl_b8fe.xs:22:21: macro Copy requires 4 arguments, but only 1 given
Editor_pl_b8fe.xs:22: variable or field `Copy' declared void
Editor_pl_b8fe.xs:22: `Copy' declared as a `virtual' field
Editor_pl_b8fe.xs:32:19: macro Copy requires 4 arguments, but only 1 given
Editor_pl_b8fe.xs:32: syntax error before `{' token
Editor_pl_b8fe.c:55: confused by earlier errors, bailing out
make: *** [Editor_pl_b8fe.o] Error 1
A problem was encountered while attempting to compile and install your
Inline
CPP code. The command that failed was:
make out.make 21
The build directory was:
/home/sarkar/Perl/root_examples/_Inline/build/Editor_pl_b8fe
To debug the problem, cd to the build directory, and inspect the output
files.
at Editor.pl line 0
INIT failed--call queue aborted.
--
http://www.piersharding.com
http://search.cpan.org/~piers/
pgp9GyvWGzneL.pgp
Description: PGP signature
