module-build-general Mailing List for Module::Build (Page 154)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dave R. <au...@ur...> - 2003-10-10 22:53:11
|
See below sig. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ --- manifypods.t.~1.5.~ 2003-08-19 08:33:06.000000000 -0500 +++ manifypods.t 2003-10-10 17:52:27.000000000 -0500 @@ -1,7 +1,6 @@ -#!/usr/bin/perl +#!/usr/bin/perl -w use strict; -use warnings; use File::Spec; use File::Path qw( rmtree ); |
|
From: Ken W. <ke...@ma...> - 2003-10-10 21:01:31
|
Patch applied, thanks. -Ken On Thursday, October 9, 2003, at 10:29 AM, Steve Purkis wrote: > On Wednesday, October 1, 2003, at 11:10 pm, Mark Stosberg wrote: > >> Hello, >> >> Today I looked into seeing what the "docs" action does. When I ran it, >> the output looks identical to just running "./Build". >> >> So I looked at the code. It looks like they are in fact doing the >> exact >> same thing. If you don't specify an action, "build" is the default. >> "build" calls the "code" action, and then "docs" action. >> >> If you call the "docs" action directly, it depends on the "code" >> action, >> so again the "code" ation gets called, followed by the "docs" action. >> >> So it doesn't seem an incredibly useful action at the moment. >> :). It would seem more useful if you could build the docs without >> depending on the code being built, but I'm not sure if that will make >> sense from a technical perspective. > > That's not really possible, seeing as building your codebase might > involve generating some documentation specific to that build (or > platform). > > And the split is not entirely useless as it may seem... :) The 'code' > action doesn't depend on the 'docs' action, which is good because > 'test' depends on 'code', which means you don't have to build the docs > to test your code. (whereas, if there were only one 'build' action, > 'test' would have to rely on it.) > > >> At any rate, the docs could say something like: >> >> docs >> >> Builds all the man pages for the binary and library POD. >> This action depends on the code being built, and will call the >> 'code' action if it hasn't already run. By default this action >> gives the exact seems results as simply running "./Build". > > Good idea, though I'd say it slightly differently by referring to > 'docs' from the 'build' action. I've attached a patch against current > CVS updates the pod for 'build' and introduces 'code', and 'docs'. > > hth, > -Steve > <Module-Build-docs.patch> |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:55:56
|
Thanks, applied in CVS for the next release. -Ken On Wednesday, October 8, 2003, at 03:18 PM, Paul Johnson wrote: > ... and I don't think it should. Here's a patch. > > I'm not subscribed, so please CC any replies to me. > > --- Module/Build/Base.pm.org 2003-10-07 17:12:31.000000000 +0200 > +++ Module/Build/Base.pm 2003-10-08 22:09:07.000000000 +0200 > @@ -972,9 +972,9 @@ > $self->depends_on('code'); > > # Do everything in our power to work with all versions of > Test::Harness > - local ($Test::Harness::switches, > - $Test::Harness::Switches, > - $ENV{HARNESS_PERL_SWITCHES}) = ($p->{debugger} ? '-w -d' : > '') x 3; > + local ($Test::Harness::switches, $Test::Harness::Switches) = ('', > ''); > + local $ENV{HARNESS_PERL_SWITCHES} = $ENV{HARNESS_PERL_SWITCHES} . > + ($p->{debugger} ? ' -w -d' : > ''); > > local ($Test::Harness::verbose, > $Test::Harness::Verbose, > > -- > Paul Johnson - pa...@pj... > http://www.pjcj.net > > > |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:50:16
|
Hi Terrence, So, this bug is that it doesn't respect PREFIX, or that it uses '::' strings in the manpage names? The latter has been fixed for the next release. The former may not be fixed anytime soon, and perhaps deserves at least a warning (possibly a die()) when encountered. -Ken On Wednesday, October 8, 2003, at 10:29 AM, Terrence Brannon wrote: > This first issue is trivial, but here it is using Perl-5.8.0. > > ~/.cpan/build/Module-Build-0.20 $ ls > Build Changes MANIFEST Makefile README lib > Build.PL INSTALL.txt META.yml Makefile.PL _build t > ~/.cpan/build/Module-Build-0.20 $ less README > ~/.cpan/build/Module-Build-0.20 $ perl Makefile.PL > PREFIX=$PREFIX > perl Build.PL config=prefix=/home/metaperl/install > Checking whether your kit is complete... > Looks good > Deleting Build > Removed previous script 'Build' > Creating new 'Build' script for 'Module-Build' version '0.20' > ~/.cpan/build/Module-Build-0.20 $ ./Build 2> Build.err > > Build.out > ~/.cpan/build/Module-Build-0.20 $ > > -------------------------------- > > Build.err: > > Can't open blib/libdoc/Module::Build::Platform::Unix.3pm for writing: > No such file or directory > at > /home/metaperl/.cpan/build/Module-Build-0.20/lib/Module/Build/Base.pm > line 1286 > > ---------------------------------- > > Build.out: > > lib/Module/Build/Platform/darwin.pm -> > blib/lib/Module/Build/Platform/darwin.pm > lib/Module/Build/Platform/MacOS.pm -> > blib/lib/Module/Build/Platform/MacOS.pm > lib/Module/Build/Compat.pm -> blib/lib/Module/Build/Compat.pm > lib/Module/Build/Platform/RiscOS.pm -> > blib/lib/Module/Build/Platform/RiscOS.pm > lib/Module/Build/Platform/VOS.pm -> > blib/lib/Module/Build/Platform/VOS.pm > lib/Module/Build/Platform/Windows.pm -> > blib/lib/Module/Build/Platform/Windows.pm > lib/Module/Build/Platform/Unix.pm -> > blib/lib/Module/Build/Platform/Unix.pm > lib/Module/Build/Platform/Amiga.pm -> > blib/lib/Module/Build/Platform/Amiga.pm > lib/Module/Build/Base.pm -> blib/lib/Module/Build/Base.pm > lib/Module/Build/Platform/EBCDIC.pm -> > blib/lib/Module/Build/Platform/EBCDIC.pm > lib/Module/Build/Platform/MPEiX.pm -> > blib/lib/Module/Build/Platform/MPEiX.pm > lib/Module/Build/Platform/VMS.pm -> > blib/lib/Module/Build/Platform/VMS.pm > lib/Module/Build.pm -> blib/lib/Module/Build.pm > lib/Module/Build/PPMMaker.pm -> blib/lib/Module/Build/PPMMaker.pm > lib/Module/Build/Cookbook.pm -> blib/lib/Module/Build/Cookbook.pm > lib/Module/Build/Platform/Default.pm -> > blib/lib/Module/Build/Platform/Default.pm > Manifying blib/lib/Module/Build/Platform/Unix.pm -> > blib/libdoc/Module::Build::Platform::Unix.3pm > > > > > > |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:44:46
|
Hi Stephen,
Thanks, I've fixed it in CVS. I meant check_installed_version(), not
check_installed_status().
-Ken
On Thursday, October 2, 2003, at 08:43 AM, Stephen J. Smith wrote:
> Line 61 of runthrough.t calls check_installed_status() and checks for a
> true result. check_installed_status() returns a hash which always
> evaluates to true.
>
> Maybe this hasn't been caught because t/Sample/META.yml is part of the
> distribution? Maybe the test code should unlink() it before invoking
> distdir?
>
> The below patch uses the same check that Base.pm uses for a similar
> purpose. There are other approaches of course.
>
> diff -uNr Module-Build-0.20.orig/t/runthrough.t
> Module-Build-0.20/t/runthrough.t
> --- Module-Build-0.20.orig/t/runthrough.t 2003-08-26
> 14:49:15.000000000 -0400
> +++ Module-Build-0.20/t/runthrough.t 2003-10-02 09:18:45.000000000
> -0400
> @@ -58,7 +58,7 @@
> print $output;
> print "^^^^^^^^^^^^^^^^^^^^^ Sample/test.pl output
> ^^^^^^^^^^^^^^^^^^^^^\n";
>
> -if ($build->check_installed_status('YAML', 0)) {
> +if (eval {require YAML; 1}) {
> eval {$build->dispatch('disttest')};
> ok $@, '';
>
> End of Patch.
>
>
>
>
|
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:42:19
|
Hi Brett, This is a bug in Red Hat 9. See the page https://rt.cpan.org/Ticket/Display.html?id=3D3687 where it has been previously reported. Thanks. -Ken On Wednesday, October 1, 2003, at 02:50 PM, Brett Kettlewell wrote: > I don't write Perl but I'm installing modules for an application (RT) =20= > on a Redhat9 server which has dependencies on a myriad of=A0Perl =20 > modules.=A0 I've loaded a ton of modules, but the last two are both =20= > dependant on Module::Build, and I can't get that to load.=A0 I've = tried =20 > to install from doing a "% perl MCPAN -e 'install Module::Build'" and =20= > from actually downloading it, un-tarring it, creating the script, =20 > making, and testing it.=A0 Both ways I get the same errors: > =A0 > t/xs............ok 6/11Can't exec "gcc'": No such file or directory at = =20 > /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/=20 > Build/Base.pm line 1917, <File0000> line 14. > error building lib/XSTest.o from 'lib/XSTest.so' at =20 > /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/=20 > Build/Base.pm line 1797, <File0000> line 14. > t/xs............NOK 8# Test 8 got: 'error building lib/XSTest.o from =20= > 'lib/XSTest.so' at =20 > /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/=20 > Build/Base.pm line 1797, <File0000> line 14. > ' (t/xs.t at line 50) > # Expected: '' > # t/xs.t line 50 is: ok $@, ''; > > Of my 50 or so module dependencies, this is the last one I have to =20 > install, and then I can get on to configuring the application.=A0 Has =20= > anyone received these errors when doing their make test?=A0 Is there a = =20 > workaround? > =A0 > > Brett M. Kettlewell > Trauner, Cohen & Thomas > Br...@tc... > 888-696-1900 x1023 > |
|
From: Chris D. <ch...@cl...> - 2003-10-10 20:39:28
|
On Friday, October 10, 2003, at 01:57 PM, Ken Williams wrote: > > On Friday, October 10, 2003, at 01:42 PM, Chris Dolan wrote: > >> I just posted a bug for YAML that affects M::B's creation of META.yml >> files. >> http://rt.cpan.org/NoAuth/Bug.html?id=4066 >> >> YAML's Dump method doesn't respect whether a scalar is a string or a >> number, so trailing zeros on version numbers are dropped when reading >> .yml files. See the above URL for a very simple failing example. >> >> I haven't yet thought of a workaround that doesn't involve changes to >> YAML.pm. > > Hi Chris, > > Yeah, this is an unfortunate bug in YAML. Apparently there's a new > version of YAML.pm that Brian's been working on, and it's been > released in a preliminary version at > http://search.cpan.org/~ingy/YAML-Parser-Syck-0.01/ . > > Fortunately the YAML we emit is correct, and it's only YAML.pm reading > it back in that's buggy. So we don't actually need to fix any bugs in > Module::Build or rely on Brian's new parser. > > -Ken Sounds good. One possible workaround would be if YAML would output version: '1.10' instead of version: 1.10 which should be safe against any valid YAML parser implementation. But, again, that relies on a change to YAML, not M::B. Sigh. I'll read up on Syck. Chris |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:36:43
|
On Monday, September 29, 2003, at 02:50 PM, Bart Parliman wrote: > I noticed that it's using the literal "$(PERL_INC)/perl.exp" and > "$(BASEEXT).exp" strings during the 'ld' rather than > interpolating them. > > At first I thought that I had built perl incorrectly, since these > literal values are in the "perl -V" output for lddlflags (see > below). After looking at the vendor's built-in perl on a > different machine (5.6.0), it appears that 'lddlflags' has these > two values in there as well. Yeah, I wasn't aware that it was legal to have $(VARIABLE) interpolation in these Config.pm strings. =( Is this typical? Do other platforms do this too? How do those variables get set? Since Module::Build uses the multi-argument form of system(), it doesn't run any of the arguments through the shell. This is much safer in terms of security and preventing accidents, so I'm not terribly excited about changing it. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:32:19
|
Hi, Not sure I understand. Config.pm is a standard part of the perl distribution. -Ken On Monday, September 29, 2003, at 04:44 AM, iv...@ab... wrote: > I am making a very large recursive > subclassing, all recursive calls use > > use lib "."; > > I have file called Config.pm which duplicate > Module::Build internal file.... > > It will be good to rename the distribution > files to some iregular names _C_onfig.pm so > not to duplicate and mismatch with the user > distribution. > > > |
|
From: Ken W. <ke...@ma...> - 2003-10-10 20:30:22
|
Okay, I've committed this patch. Thanks. -Ken On Wednesday, September 24, 2003, at 01:06 AM, Yitzchak Scott-Thoennes wrote: > Couldn't install Module::Build...the manpage names contain colons. > Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2 > ($^O eq 'uwin' and 'os2', respectively) also use '.', but have no > special code in Module::Build. MakeMaker uses '__' for DOS, > Module::Build uses '.' (via Platform/Windows.pm). > > I left os_type as Unix for cygwin. Darwin does the same. You might > think about implementing an os_flavor ala MakeMaker instead (where one > platform can list multiple types) with an os_flavor_is(@foo) routine > checking if any of the @foo types apply. > > Would have been nice if install.t had caught the problem instead of > the actual install failing midway, but the install.t only tries a > top-level module name. > > t/xs.t is failing tests 4 and 8. I'm not sure how to translate the > other things MM_Cygwin does into Module::Build terms. |
|
From: Ken W. <ke...@ma...> - 2003-10-10 18:57:16
|
On Friday, October 10, 2003, at 01:42 PM, Chris Dolan wrote: > I just posted a bug for YAML that affects M::B's creation of META.yml > files. > http://rt.cpan.org/NoAuth/Bug.html?id=4066 > > YAML's Dump method doesn't respect whether a scalar is a string or a > number, so trailing zeros on version numbers are dropped when reading > .yml files. See the above URL for a very simple failing example. > > I haven't yet thought of a workaround that doesn't involve changes to > YAML.pm. Hi Chris, Yeah, this is an unfortunate bug in YAML. Apparently there's a new version of YAML.pm that Brian's been working on, and it's been released in a preliminary version at http://search.cpan.org/~ingy/YAML-Parser-Syck-0.01/ . Fortunately the YAML we emit is correct, and it's only YAML.pm reading it back in that's buggy. So we don't actually need to fix any bugs in Module::Build or rely on Brian's new parser. -Ken |
|
From: Chris D. <ch...@cl...> - 2003-10-10 18:43:17
|
I just posted a bug for YAML that affects M::B's creation of META.yml files. http://rt.cpan.org/NoAuth/Bug.html?id=4066 YAML's Dump method doesn't respect whether a scalar is a string or a number, so trailing zeros on version numbers are dropped when reading .yml files. See the above URL for a very simple failing example. I haven't yet thought of a workaround that doesn't involve changes to YAML.pm. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. ch...@cl..., 294-7900, 211 S Paterson, Madison WI 53703 |
|
From: Richard C. <ric...@un...> - 2003-10-10 08:39:47
|
On Thu, Oct 09, 2003 at 09:50:04PM -0700, Terrence Brannon wrote:
> Randy W. Sims wrote:
>
> >I believe you may have misread the previous message. This should
> >probably be
> >
> >> extra_linker_flags => '-l$Config{libperl}'
>
> you're right: even after double quotes it does not include the extra
> linker flags
The %Config hash is defined by the Config module.
Add to the top of your Build.PL:
use strict;
use Config;
No I'm not kidding about the use strict;
--
Richard Clamp <ric...@un...>
|
|
From: Randy W. S. <Ra...@Th...> - 2003-10-10 05:01:21
|
On 10/10/2003 12:50 AM, Terrence Brannon wrote: > ahh, I am using 5.8.0... but you speak on M::B::Platform::Windows when > an earlier msg indicated that Cygwin used M::B::Platform::Unix, most of > which defaults to M::B::Base Cygwin is a little of Unix and a little of Windows. I have downloaded Cygwin and am now installing. The download was quick. The installation is taking a loooooonnnnnnnnngggggggg time. Randy. |
|
From: Terrence B. <met...@ur...> - 2003-10-10 04:50:22
|
Randy W. Sims wrote:
> I believe you may have misread the previous message. This should
> probably be
>
>> extra_linker_flags => '-l$Config{libperl}'
>>
>> That is, import the library called libperl.{dll,so,dylib,whatever}
>>
>> Chris
>
>
> Yes, except that should be double quotes, and there seems to be
> another problem in that none of that ended up on the command line.
you're right: even after double quotes it does not include the extra
linker flags
>
> gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a \
> -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
> -s -L/usr/local/lib lib/XSTest.o
>
> I'm not real familiar with the build process under Cygwin. When I
> wrote the stuff in M::B::Platform::Windows it was my intention to add
> support for Cygwin, UWIN, djgpp (maybe Interix & MKS) and I have no
> idea how this will work with Windows CE, but I never could get a
> working Cygwin & Perl on my system (some problem with MakeMaker) and I
> also didn't have a lot of spare time. I'll try to revisit it now as
> traffic on P5P seems to indicate that a lot of those problems have
> been solved with perl-5.8.1.
ahh, I am using 5.8.0... but you speak on M::B::Platform::Windows when
an earlier msg indicated that Cygwin used M::B::Platform::Unix, most of
which defaults to M::B::Base
|
|
From: Ken W. <ke...@ma...> - 2003-10-10 02:29:02
|
Hi all, I just realized why I haven't seen much activity on the Module-Build list lately - sourceforge unsubscribed me on September 29! Jeez, set off *one* little infinite mail loop (well, two...). I'm back on now, and I'm going to look at the archives to see what I missed. Thanks to Randy Sims for CC-ing me on a thread. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-10-10 02:12:52
|
On 10/9/2003 5:32 PM, Ken Y. Clark wrote: >>On Thursday, October 9, 2003, at 04:14 PM, Andrew J. Korty wrote: >> >> >>>Greetings. I've been trying to decide whether to use Module::Build >>>for a new project I'm working on. >>> >>>One thing that's very difficult with MakeMaker is installing files >>>other than scripts and modules. I often want to install configuration >>>files in /etc, Mason components in the document root, etc. I had been >>>doing this with MakeMaker by overriding the method that produces the >>>install target and substituting commands to install files to other >>>destinations. Can Module::Build do this more elegantly? >>> >>>I also wonder if Module::Build can help me with another problem >>>brought about by a recent change in MakeMaker. Although I can still >>>specify custom parameters that may be passed via environment variables >>>when executing Makefile.PL, it will no longer let me pass my own >>>custom parameters to WriteMakefile. I do that for things like Mason >>>component roots. We need to know the component root at install time >>>so we can install the components there, but we also need it at run >>>time to create the ApacheHandler object. So I'd like to be able to >>>pass it just once to WriteMakefile, >>> >>>-- >>>Andrew J. Korty, Principal Security Engineer, GCIA, GCFA >>>Office of the Vice President for Information Technology >>>Indiana University > > > Andrew, > > I wanted to use Module::Build for this exact same reason. I found it > pretty easy to subclass M::B and install templates and config files > and such. You can see what I did (and possibly tell me if I could do > it better) by downloading the "cmap-0.09.tar.gz" from here: > > https://sourceforge.net/project/showfiles.php?group_id=27707 > > ky Personally, I'd like to see another namespace maybe M::B::Configure or M::Configure where Modules could be added that performed tasks similar to the autotools. There could be an ::OS module to get common paths and other OS specific config info. Then there could be others like Apache, WindowingSystem, etc. Then M::B could provide the tools for installing such as copy_if_modified, etc. (which would need to be modified to take another flag to indicate how and where to backup the original file.) just my $.02 Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope |
|
From: Randy W. S. <Ra...@Th...> - 2003-10-10 01:20:46
|
On 10/9/2003 9:45 AM, Chris Dolan wrote:
> On Thursday, October 9, 2003, at 08:32 AM, Terrence Brannon wrote:
>
>> Randy W. Sims wrote:
>>
>>>
>>> Adding "-l$Config{libperl}" to the linker command should remove all
>>> the unresolved references.
>>>
>>
>> extra_linker_flags => '-L $Config{libperl}'
>
>
> I believe you may have misread the previous message. This should
> probably be
> extra_linker_flags => '-l$Config{libperl}'
>
> That is, import the library called libperl.{dll,so,dylib,whatever}
>
> Chris
Yes, except that should be double quotes, and there seems to be another
problem in that none of that ended up on the command line.
gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a \
-Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib lib/XSTest.o
I'm not real familiar with the build process under Cygwin. When I wrote
the stuff in M::B::Platform::Windows it was my intention to add support
for Cygwin, UWIN, djgpp (maybe Interix & MKS) and I have no idea how
this will work with Windows CE, but I never could get a working Cygwin &
Perl on my system (some problem with MakeMaker) and I also didn't have a
lot of spare time. I'll try to revisit it now as traffic on P5P seems to
indicate that a lot of those problems have been solved with perl-5.8.1.
I'm thinking now that it might be slightly more complicated that my
previous message may have indicated. $Config{lddlflags} &
$Config{libperl} (if it's not already in $Config{lddlflags} on Cygwin)
should be on that command line, but do not appear to be. Also, I think
Cygwin will require the same prelink step as Windows (same sub can be
used as is).
I had originally thought that Cygwin would inherit from
M::B::Platform::Windows::GCC, but that may have been ignorance on my
part. I'll see what MakeMaker does and follow suite. One thing I'm
afraid of is that if it is significantly different from Windows::GCC and
the default Unix like build process, I think things need to be
reorganized a good bit: The class hierarchy cludge in Platform::Windows
needs to be fixed and the default compile routines should be pulled out
of M::B and put in a separate class (M::B::cc ???) and move
Platform::Windows::GCC, ::BCC, & ::MSC so that they are subclasses of
M::B::cc.
I'll defer to Ken on the design. Meanwhile, I'm downloading the latest
Cygwin and will play for a while.
Randy.
|
|
From: Ken Y. C. <kc...@lo...> - 2003-10-09 21:32:42
|
> On Thursday, October 9, 2003, at 04:14 PM, Andrew J. Korty wrote:
>=20
> >Greetings. I've been trying to decide whether to use Module::Build
> >for a new project I'm working on.
> >
> >One thing that's very difficult with MakeMaker is installing files
> >other than scripts and modules. I often want to install configuration
> >files in /etc, Mason components in the document root, etc. I had been
> >doing this with MakeMaker by overriding the method that produces the
> >install target and substituting commands to install files to other
> >destinations. Can Module::Build do this more elegantly?
> >
> >I also wonder if Module::Build can help me with another problem
> >brought about by a recent change in MakeMaker. Although I can still
> >specify custom parameters that may be passed via environment variables
> >when executing Makefile.PL, it will no longer let me pass my own
> >custom parameters to WriteMakefile. I do that for things like Mason
> >component roots. We need to know the component root at install time
> >so we can install the components there, but we also need it at run
> >time to create the ApacheHandler object. So I'd like to be able to
> >pass it just once to WriteMakefile,
> >
> >--=20
> >Andrew J. Korty, Principal Security Engineer, GCIA, GCFA
> >Office of the Vice President for Information Technology
> >Indiana University
Andrew,
I wanted to use Module::Build for this exact same reason. I found it
pretty easy to subclass M::B and install templates and config files
and such. You can see what I did (and possibly tell me if I could do
it better) by downloading the "cmap-0.09.tar.gz" from here:
https://sourceforge.net/project/showfiles.php?group_id=3D27707
ky
|
|
From: Ken W. <ke...@ma...> - 2003-10-09 21:19:18
|
Hi Andrew, Could you please send this message to the module-build list, at mod...@li... ? That way others could benefit from the answers too. If you don't feel like subscribing to the list, I'll just approve your message(s) by hand. Thanks, -Ken On Thursday, October 9, 2003, at 04:14 PM, Andrew J. Korty wrote: > Greetings. I've been trying to decide whether to use Module::Build > for a new project I'm working on. > > One thing that's very difficult with MakeMaker is installing files > other than scripts and modules. I often want to install configuration > files in /etc, Mason components in the document root, etc. I had been > doing this with MakeMaker by overriding the method that produces the > install target and substituting commands to install files to other > destinations. Can Module::Build do this more elegantly? > > I also wonder if Module::Build can help me with another problem > brought about by a recent change in MakeMaker. Although I can still > specify custom parameters that may be passed via environment variables > when executing Makefile.PL, it will no longer let me pass my own > custom parameters to WriteMakefile. I do that for things like Mason > component roots. We need to know the component root at install time > so we can install the components there, but we also need it at run > time to create the ApacheHandler object. So I'd like to be able to > pass it just once to WriteMakefile, > > -- > Andrew J. Korty, Principal Security Engineer, GCIA, GCFA > Office of the Vice President for Information Technology > Indiana University |
|
From: Steve P. <sp...@qu...> - 2003-10-09 15:29:53
|
On Wednesday, October 1, 2003, at 11:10 pm, Mark Stosberg wrote: > Hello, > > Today I looked into seeing what the "docs" action does. When I ran it, > the output looks identical to just running "./Build". > > So I looked at the code. It looks like they are in fact doing the exact > same thing. If you don't specify an action, "build" is the default. > "build" calls the "code" action, and then "docs" action. > > If you call the "docs" action directly, it depends on the "code" > action, > so again the "code" ation gets called, followed by the "docs" action. > > So it doesn't seem an incredibly useful action at the moment. > :). It would seem more useful if you could build the docs without > depending on the code being built, but I'm not sure if that will make > sense from a technical perspective. That's not really possible, seeing as building your codebase might involve generating some documentation specific to that build (or platform). And the split is not entirely useless as it may seem... :) The 'code' action doesn't depend on the 'docs' action, which is good because 'test' depends on 'code', which means you don't have to build the docs to test your code. (whereas, if there were only one 'build' action, 'test' would have to rely on it.) > At any rate, the docs could say something like: > > docs > > Builds all the man pages for the binary and library POD. > This action depends on the code being built, and will call the > 'code' action if it hasn't already run. By default this action > gives the exact seems results as simply running "./Build". Good idea, though I'd say it slightly differently by referring to 'docs' from the 'build' action. I've attached a patch against current CVS updates the pod for 'build' and introduces 'code', and 'docs'. hth, -Steve |
|
From: Chris D. <ch...@cl...> - 2003-10-09 13:46:00
|
On Thursday, October 9, 2003, at 08:32 AM, Terrence Brannon wrote:
> Randy W. Sims wrote:
>
>>
>> Adding "-l$Config{libperl}" to the linker command should remove all
>> the unresolved references.
>>
>
> extra_linker_flags => '-L $Config{libperl}'
I believe you may have misread the previous message. This should
probably be
extra_linker_flags => '-l$Config{libperl}'
That is, import the library called libperl.{dll,so,dylib,whatever}
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
ch...@cl..., 294-7900, 211 S Paterson, Madison WI 53703
|
|
From: Terrence B. <met...@ur...> - 2003-10-09 13:32:16
|
Randy W. Sims wrote:
> On 10/8/2003 11:45 AM, Terrence Brannon wrote:
>
>> gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
>> -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
>> -s -L/usr/local/lib lib/XSTest.o
>
>
> Adding "-l$Config{libperl}" to the linker command should remove all
> the unresolved references.
>
I just attempted to do this by editing Build.PL ni the home directory:
my $build = new Module::Build
(
module_name => 'Module::Build',
license => 'perl',
requires => {
'perl' => '5.005_03',
'Config' => 0,
'Data::Dumper' => 0,
'File::Basename' => 0,
'File::Compare' => 0,
'File::Copy' => 0,
'File::Find' => 0,
'File::Path' => 0,
'File::Spec' => 0,
'ExtUtils::Install' => 0,
'IO::File' => 0,
'Cwd' => 0,
},
recommends => {
'YAML' => 0.35,
'Archive::Tar' => '1.00',
'ExtUtils::Install' => 0.30,
'ExtUtils::ParseXS' => 2.02,
# 'Module::Signature' => 0.21, # Our support isn't good
enough yet
},
build_requires => {
Test => 0,
},
extra_linker_flags => '-L $Config{libperl}'
);
but the problem is still there (sorry for the ugly transcript):
~/.cpan/build/Module-Build-0.20 $ make test
/usr/bin/perl Build test
t/basic.........
t/basic.........ok 1/19
t/basic.........ok 2/19
t/basic.........ok 3/19
t/basic.........ok 4/19
t/basic.........ok 5/19
t/basic.........ok 6/19
t/basic.........ok 7/19
t/basic.........ok 8/19
t/basic.........ok 9/19
t/basic.........ok 10/19
t/basic.........ok 11/19
t/basic.........ok 12/19
t/basic.........ok 13/19
t/basic.........ok 14/19
t/basic.........ok 15/19
t/basic.........ok 16/19
t/basic.........ok 17/19
t/basic.........ok 18/19
t/basic.........ok 19/19
t/basic.........ok
t/compat........
t/compat........ok 1/23
t/compat........ok 2/23
t/compat........ok 3/23
t/compat........ok 4/23Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
make[1]: *** [all] Error 255
# Failed test 5 in t/compat.t at line 33
t/compat........NOK 5
t/compat........ok 6/23
t/compat........ok 7/23
t/compat........ok 8/23
t/compat........ok 9/23
t/compat........ok 10/23
t/compat........ok 11/23Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
make[1]: *** [all] Error 255
# Failed test 12 in t/compat.t at line 33 fail #2
t/compat........NOK 12
t/compat........ok 13/23
t/compat........ok 14/23
t/compat........ok 15/23
t/compat........ok 16/23
t/compat........ok 17/23
t/compat........ok 18/23
t/compat........ok 19/23
t/compat........ok 20/23
t/compat........ok 21/23
t/compat........ok 22/23
t/compat........ok 23/23
t/compat........FAILED tests 5, 12
Failed 2/23 tests, 91.30% okay
t/extend........
t/extend........ok 1/9
t/extend........ok 2/9
t/extend........ok 3/9
t/extend........ok 4/9
t/extend........ok 5/9
t/extend........ok 6/9
t/extend........ok 7/9
t/extend........ok 8/9
t/extend........ok 9/9
t/extend........ok
t/install.......
t/install.......ok 1/17
t/install.......ok 2/17# Test 3 got: 'Can't open
blib/libdoc/Sample::Docs.3pm for writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
' (t/install.t at line 32)
# Expected: ''
t/install.......NOK 3# Failed test 4 in t/install.t at line 37
t/install.......NOK 4# Test 5 got: 'Can't open
blib/libdoc/Sample::Docs.3pm for writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
' (t/install.t at line 42)
t/install.......NOK 5# Expected: ''
# Failed test 6 in t/install.t at line 46
t/install.......NOK 6# Test 7 got: 'Can't open
blib/libdoc/Sample::Docs.3pm for writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
' (t/install.t at line 52)
t/install.......NOK 7# Expected: ''
# Failed test 8 in t/install.t at line 55
t/install.......NOK 8# Test 9 got: 'Can't open
blib/libdoc/Sample::Docs.3pm for writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
' (t/install.t at line 61)
# Expected: ''
t/install.......NOK 9
t/install.......NOK 10# Failed test 10 in t/install.t at line 64
t/install.......ok 11/17
t/install.......ok 12/17Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
t/install.......ok 13/17# Failed test 14 in t/install.t at line 80
t/install.......NOK 14Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
t/install.......ok 15/17# Failed test 16 in t/install.t at line 90
t/install.......NOK 16
t/install.......ok 17/17
t/install.......FAILED tests 3-10, 14, 16
Failed 10/17 tests, 41.18% okay
t/manifypods....
t/manifypods....ok 1/17
t/manifypods....ok 2/17Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
t/manifypods....dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 3-17
Failed 15/17 tests, 11.76% okay
t/notes.........
t/notes.........ok 1/5
t/notes.........ok 2/5
t/notes.........ok 3/5
t/notes.........ok 4/5
t/notes.........ok 5/5
t/notes.........ok
t/runthrough....
t/runthrough....ok 1/24
t/runthrough....ok 2/24
t/runthrough....ok 3/24
t/runthrough....ok 4/24
t/runthrough....ok 5/24
t/runthrough....ok 6/24
t/runthrough....ok 7/24
t/runthrough....ok 8/24
t/runthrough....ok 9/24
t/runthrough....ok 10/24
t/runthrough....ok 11/24Can't open blib/libdoc/Sample::Docs.3pm for
writing: Invalid argument
at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1286
# Test 12 got: 'Error executing 'Build' in dist directory: at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1530.
' (t/runthrough.t at line 63)
# Expected: ''
t/runthrough....NOK 12# Failed test 13 in t/runthrough.t at line 66
t/runthrough....NOK 13
t/runthrough....ok 14/24
t/runthrough....ok 15/24
t/runthrough....ok 16/24
t/runthrough....ok 17/24
t/runthrough....ok 18/24
t/runthrough....ok 19/24
t/runthrough....ok 20/24
t/runthrough....ok 21/24
t/runthrough....ok 22/24
t/runthrough....ok 23/24
t/runthrough....ok 24/24
t/runthrough....FAILED tests 12-13
Failed 2/24 tests, 91.67% okay
t/signature.....skipped
all skipped: Skipping unless $ENV{TEST_SIGNATURE} is true
t/versions......
t/versions......ok 1/2
t/versions......ok 2/2
t/versions......ok
t/xs............
t/xs............ok 1/11
t/xs............ok 2/11
t/xs............ok 3/11Creating library file: libXSTest.dll.a
lib/XSTest.o(.text+0x31):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x49):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x53):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x61):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x6b):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x8c):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x96):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xb1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xc3):XSTest.c: undefined reference to `_Perl_croak'
lib/XSTest.o(.text+0xcf):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xf4):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xfe):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x117):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x121):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x139):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x143):XSTest.c: undefined reference to
`_Perl_Tcurpad_ptr'
lib/XSTest.o(.text+0x151):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x15b):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x17d):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x187):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x19a):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to `_Perl_sv_setiv'
lib/XSTest.o(.text+0x1c9):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1d3):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x1e1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1eb):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x208):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x216):XSTest.c: undefined reference to `_Perl_mg_set'
lib/XSTest.o(.text+0x228):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x232):XSTest.c: undefined reference to
`_Perl_sv_newmortal'
lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x252):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x260):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x271):XSTest.c: undefined reference to `_Perl_sv_2iv'
lib/XSTest.o(.text+0x2b0):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2ba):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x2c6):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2d0):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x2de):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2e8):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x302):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x30c):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x31f):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x342):XSTest.c: undefined reference to `_Perl_newXS'
lib/XSTest.o(.text+0x34e):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x358):XSTest.c: undefined reference to
`_Perl_Isv_yes_ptr'
lib/XSTest.o(.text+0x366):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x370):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x381):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x38b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x399):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3a3):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
-Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib lib/XSTest.o
# Test 4 got: 'error building lib/XSTest.o from 'lib/XSTest.dll' at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797, <File0000> line 14.
' (t/xs.t at line 33)
# Expected: ''
t/xs............NOK 4
t/xs............ok 5/11
t/xs............ok 6/11Creating library file: libXSTest.dll.a
lib/XSTest.o(.text+0x31):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x49):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x53):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x61):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x6b):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x8c):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x96):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xb1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xc3):XSTest.c: undefined reference to `_Perl_croak'
lib/XSTest.o(.text+0xcf):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xf4):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xfe):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x117):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x121):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x139):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x143):XSTest.c: undefined reference to
`_Perl_Tcurpad_ptr'
lib/XSTest.o(.text+0x151):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x15b):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x17d):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x187):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x19a):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to `_Perl_sv_setiv'
lib/XSTest.o(.text+0x1c9):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1d3):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x1e1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1eb):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x208):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x216):XSTest.c: undefined reference to `_Perl_mg_set'
lib/XSTest.o(.text+0x228):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x232):XSTest.c: undefined reference to
`_Perl_sv_newmortal'
lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x252):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x260):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x271):XSTest.c: undefined reference to `_Perl_sv_2iv'
lib/XSTest.o(.text+0x2b0):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2ba):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x2c6):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2d0):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x2de):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2e8):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x302):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x30c):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x31f):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x342):XSTest.c: undefined reference to `_Perl_newXS'
lib/XSTest.o(.text+0x34e):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x358):XSTest.c: undefined reference to
`_Perl_Isv_yes_ptr'
lib/XSTest.o(.text+0x366):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x370):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x381):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x38b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x399):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3a3):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
-Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib lib/XSTest.o
error building lib/XSTest.o from 'lib/XSTest.dll' at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797, <File0000> line 14.
t/xs............ok 7/11Creating library file: libXSTest.dll.a
lib/XSTest.o(.text+0x31):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x49):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x53):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x61):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x6b):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x8c):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x96):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xb1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xc3):XSTest.c: undefined reference to `_Perl_croak'
lib/XSTest.o(.text+0xcf):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0xf4):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0xfe):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x117):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x121):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x139):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x143):XSTest.c: undefined reference to
`_Perl_Tcurpad_ptr'
lib/XSTest.o(.text+0x151):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x15b):XSTest.c: undefined reference to `_Perl_Top_ptr'
lib/XSTest.o(.text+0x17d):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x187):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x19a):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to `_Perl_sv_setiv'
lib/XSTest.o(.text+0x1c9):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1d3):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x1e1):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x1eb):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x208):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x216):XSTest.c: undefined reference to `_Perl_mg_set'
lib/XSTest.o(.text+0x228):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x232):XSTest.c: undefined reference to
`_Perl_sv_newmortal'
lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x252):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x260):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x271):XSTest.c: undefined reference to `_Perl_sv_2iv'
lib/XSTest.o(.text+0x2b0):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2ba):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x2c6):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2d0):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x2de):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x2e8):XSTest.c: undefined reference to
`_Perl_Tmarkstack_ptr_ptr'
lib/XSTest.o(.text+0x302):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x30c):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x31f):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x342):XSTest.c: undefined reference to `_Perl_newXS'
lib/XSTest.o(.text+0x34e):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x358):XSTest.c: undefined reference to
`_Perl_Isv_yes_ptr'
lib/XSTest.o(.text+0x366):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x370):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
lib/XSTest.o(.text+0x381):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x38b):XSTest.c: undefined reference to
`_Perl_Tstack_sp_ptr'
lib/XSTest.o(.text+0x399):XSTest.c: undefined reference to
`_Perl_Gcurinterp_ptr'
lib/XSTest.o(.text+0x3a3):XSTest.c: undefined reference to
`_Perl_Tstack_base_ptr'
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
-Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib lib/XSTest.o
# Test 8 got: 'error building lib/XSTest.o from 'lib/XSTest.dll' at
/home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797, <File0000> line 14.
' (t/xs.t at line 50)
# Expected: ''
t/xs............NOK 8
t/xs............ok 9/11
t/xs............ok 10/11
t/xs............ok 11/11
t/xs............FAILED tests 4, 8
Failed 2/11 tests, 81.82% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/compat.t 23 2 8.70% 5 12
t/install.t 17 10 58.82% 3-10 14 16
t/manifypods.t 255 65280 17 15 88.24% 3-17
t/runthrough.t 24 2 8.33% 12-13
t/xs.t 11 2 18.18% 4 8
1 test skipped.
Failed 5/10 test scripts, 50.00% okay. 31/127 subtests failed, 75.59% okay.
make: *** [test] Error 14
~/.cpan/build/Module-Build-0.20 $
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2003-10-09 12:41:54
|
On Thu, Oct 09, 2003 at 03:57:42AM -0700, Terrence Brannon <met...@ur...> wrote:
> Randy W. Sims wrote:
>
> >On 10/8/2003 11:45 AM, Terrence Brannon wrote:
> >
> >>gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
> >>-Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
> >>-s -L/usr/local/lib lib/XSTest.o
> >
> >
> >Adding "-l$Config{libperl}" to the linker command should remove all
> >the unresolved references.
>
> I am not sure how I am supposed to do this... I added:
>
> $path .= ' -l$Config{libperl} ' ;
>
> to sub format_linker_cmd in package Module::Build::Platform::Windows
> (because I did not see a Cygwin package).
>
> but that did not alter the command-line and the test still has the same
> problems
Right now, cygwin uses Module::Build::Platform::Unix, not Windows.
|
|
From: Terrence B. <met...@ur...> - 2003-10-09 10:57:51
|
Randy W. Sims wrote:
> On 10/8/2003 11:45 AM, Terrence Brannon wrote:
>
>> gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a
>> -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
>> -s -L/usr/local/lib lib/XSTest.o
>
>
> Adding "-l$Config{libperl}" to the linker command should remove all
> the unresolved references.
I am not sure how I am supposed to do this... I added:
$path .= ' -l$Config{libperl} ' ;
to sub format_linker_cmd in package Module::Build::Platform::Windows
(because I did not see a Cygwin package).
but that did not alter the command-line and the test still has the same
problems
|
7 messages has been excluded from this view by a project administrator.
