t; To: perl-xs@perl.org
> Subject: Help setting up appveyor for Windows continuous integration
> testing
> Hello everyone,
>
> The specific tcc error (given at
>> https://ci.appveyor.com/project/run4flat/c-blocks/build/1.0.17#L47) is:
>>
>> C:/STRAWB~1/perl
From: David Mertens
Sent: Monday, April 25, 2016 7:16 AM
To: perl-xs@perl.org
Subject: Help setting up appveyor for Windows continuous integration testing
Hello everyone,
The specific tcc error (given at
https://ci.appveyor.com/project/run4flat/c-blocks/build/1.0.17#L47) is:
C:/STRAWB~1/perl
Hello everyone,
I am making fairly steady progress on C::Blocks. I recently decided to set
up Windows continuous integration for my projects using appveyor. (I plan
to soon set up Mac CI using a "generic" language on Mac... wish me luck.)
My problem is that on my own testing
- Original Message -
From: "ben"
To:
Sent: Thursday, February 09, 2012 12:38 PM
Subject: Automated testing failure
what is the best practice for dealing
with binary modules which depend on third party librarys? wget? die? exit
0?
Not sure what the best practice i
On Wed, Feb 08, 2012 at 06:38:24PM -0700, ben wrote:
> So I've got my module listed on cpan, and other folks are downloading
> it. Great, but it looks like mostly it's being tested mostly by
> automated scripts which is fine, but most of these systems appear to not
> have pam headers which is not.
So I've got my module listed on cpan, and other folks are downloading
it. Great, but it looks like mostly it's being tested mostly by
automated scripts which is fine, but most of these systems appear to not
have pam headers which is not. what is the best practice for dealing
with binary modules whi
Steven,
It was a linking problem. Our system is very basterdized. We have pure
version at other locations, but /usr/lib is in VERY bad shape. After I used
explicit paths it worked ok. ldd helped me to figure this out.
Thanks very much.
On Thu, 24 Mar 2005, Steven N. Hirsch wrote:
On Wed,
On Wed, 23 Mar 2005, Billy Patton wrote:
> Found these porblems with undefined symbol
>
> nm blib/arch/auto/Laff/Laff.so | grep tree_insert_and_rebalance
> U
> _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_@@GLIBCXX_3.4
> from man nm :
> "U" The symbol is undefined.
>
es this come from?
I get it to compile without a problem but testing fails.
Here's the result of testing:
Can't load
'/data/cdmg/dev/cdmg_toolbox/Laff/LaffPerl/blib/arch/auto/Laff/Laff.so' for
module Laff:
/data/cdmg/dev/cdmg_toolbox/Laff/LaffPerl/blib/a
Hi there,
I'm not 100% sure I got on the list. I expected some kind
of confirmation. I suppose I may have deleted it.
So this is a test.
Also, I want to make sure I'm in the right place. I've done
a handful of fun XS things before. For some reason I've
decided to try to embrace the most exce
I was wondering if anyone has any experiences in Software Integration
Testing
using home made or known methodologies that are being used. I came
across
one called Cyclomatic Complexity (for example)
The context being
The software system has three subsystems; Two subsystems in the kernel
and
On Sun, 17 Mar 2002, Medi Montaseri wrote:
> I then copy this .so and one msi.h to my MSI directory.
> My MSI.xs looks like this
[cut]
> My Makefile.PL is just what h2xs(1) produced.
You need to add an entry to your writemakefile 'LIBS' entry, like so:
WriteMakefile(
NAME
Hi,
I am having a linking problem while attempting to test my XS.
Your help is appreciated.
I am experiementing with an RPC procedure. I have written a C version
of my client and server (which is pretty basic, an echo server) and am
using the protocol compiler rpcgen(1).
I am now trying to writ
13 matches
Mail list logo