module-build-general

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

> > Any feedback appreciated.
> >=20

> I'm the one who wrote Windows.pm. Can you post your perl Config.pm.=20
> Other than calling Mksymlists, it looks like we need to do some
variable=20
> substitutions on some of the $Config variables, and I'll need to see=20
> Config.pm to know which ones.

I'll spare list bandwidth by sending the config output direct to you.

I had gotten things a bit closer by copying the technique you use in
Windows.pm.
Basically add a prelink_c to M::B::Base with an empty stub and then make
an AIX platform that tries to do what Windows::prelink_c() does, but the
variable substitution part is still dogging me.  I presume it's
something
similar to your format_compiler_cmd() subroutine as opposed to setting
something
in the environment based upon values from Config?

Thanks.

--=20
j.

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

> I'm having a few problems that I'll have to work out in the morning.
The exp file is
> being created, but EU::Mksyms is putting it in blib one level deeper
than the substitution
> on $lddlflags is subsequently looking for it.  I think the way that
Ken W. compiles XS
> code as part of his test suite is throwing the main M::B build into a
loop, but I can just
> bypass the test suite until I can solve the first problem.

I've updated Randy's patch to find the .exp files in the right place on
AIX, but I
don't have the necessary Windows environment to see if I've broken
things there.

The patch is attached; if someone could please test building M::B itself
and let me
know what the results are.  If it fails and you have the time, output
from building
M::B 0.21 (with and without the patch) and Pod::Coverage 0.11 and 0.12
(one uses EU::MM
while the other M::B) without the patch would help to clarify .exp file
locations.

The main problem seems to be that the generation of the .exp file is in
a common part of
M::B (Base.pm) but the use of the .exp file in the link phase is in a
platform-specific
place (Windows.pm and aix.pm).  There doesn't seem to be a single way to
tell both
EU::Mksymlists and all of the compilers out there explicitly what the
.exp or .def file
is supposed to be named.  EU::Mksymlists just knows based upon the four
platforms it
supports but doesn't return that value back to the caller.

Perhaps what is needed is to update EU::Mksymlists to both export the
platform-specific
extensions as constants and return the canonical path to the written
file back to it's
caller so that link_c() in M::B can act more intelligently.

Thanks.

RE: [Module::Build] Problem building XS modules on AIX

[Ron S. <ro...@de...>]

On Tue, 18 Nov 2003 09:36:50 -0600, James.FitzGibbon wrote:

Hi James

> The patch is attached; if someone could please test building M::B

Nothing attached here.
-- 
Ron Savage, ro...@de... on 19/11/2003. Room EF 312
Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia
Phone: +61-3-9251 7067, Fax: +61-3-9251 7604
http://www.deakin.edu.au/~rons

Re: [Module::Build] Problem building XS modules on AIX

[Randy W. S. <Ra...@Th...>]

On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
> I've updated Randy's patch to find the .exp files in the right place on
> AIX, but I
> don't have the necessary Windows environment to see if I've broken
> things there.

I've updated James' update of my patch ;) There were some Windows 
problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 
you don't pass in something for some of the arguments even if its an 
empty array or hash ref. I also changed it so that it generates the 
def/exp file in the source directory and put the correct names into 
add_to_cleanup().

James, can you please run this through the test suite one more time?

Michael, VMS wasn't calling Mksymlists before though it looks like it 
should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to 
now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is 
this correct?

> Perhaps what is needed is to update EU::Mksymlists to both export the
> platform-specific
> extensions as constants and return the canonical path to the written
> file back to it's
> caller so that link_c() in M::B can act more intelligently.
> 
> Thanks.

Seems like a harmless but beneficial change, since the name of the file 
can vary depending on $^O, and there aught to be some way to find out 
what it is without read the source.

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Michael G S. <sc...@po...>]

On Tue, Nov 18, 2003 at 09:08:38PM -0500, Randy W. Sims wrote:
> I've updated James' update of my patch ;) There were some Windows 
> problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 

This would not surprise me.


> Michael, VMS wasn't calling Mksymlists before though it looks like it 
> should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to 
> now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is 
> this correct?

Hell if I know.  I don't understand it at all.  Ask Charles Bailey.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
They had applied the blinders of steam-grilled hamburgers to my eyes.

[Module::Build] Re: [PATCH] ExtUtils::Mksymlists undefined var ref & return value

[Randy W. S. <Ra...@Th...>]

On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
 > Perhaps what is needed is to update EU::Mksymlists to both export the
 > platform-specific
 > extensions as constants and return the canonical path to the written
 > file back to it's
 > caller so that link_c() in M::B can act more intelligently.
 >

Mksymlists() now returns the name of the file written. (Derived from the 
value of the FILE parameter plus an OS specific extension.)

On 11/18/2003 10:51 PM, Michael G Schwern wrote:
> On Tue, Nov 18, 2003 at 09:08:38PM -0500, Randy W. Sims wrote:
> 
>>I've updated James' update of my patch ;) There were some Windows 
>>problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 
> 
> 
> This would not surprise me.

Fixed reference to undefined variable on MSWin32 and OS2.

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Ken W. <ke...@ma...>]

On Tuesday, November 18, 2003, at 08:08  PM, Randy W. Sims wrote:
> +sub prelink_c {
> +  my ($self, $to, $file_base) = @_;
> +  my ($p, $args) = ($self->{properties}, $self->{args});
> +
> +  return unless grep $^O, qw(aix MacOS MSWin32 os2 VMS);
> +

I think you meant

    return unless grep {$^O eq $_} qw(aix MacOS MSWin32 os2 VMS);

But I'm going to change it to add a need_prelink_c() method, default 0 
in the base class and overridden as needed.


> +  $file_base =~ tr/"//d; # remove any quotes
> +  my $basename = File::Basename::basename($file_base);
> +
> +  print "ExtUtils::Mksymlists::Mksymlists('$file_base')\n";
> +
> +  require ExtUtils::Mksymlists;
> +  ExtUtils::Mksymlists::Mksymlists( # dl. abbrev for dynamic library
> +    NAME     => $args->{dl_name}      || $p->{module_name},
> +    DLBASE   => $args->{dl_base}      || $basename,
> +    DL_VARS  => $args->{dl_vars}      || [],
> +    DL_FUNCS => $args->{dl_funcs}     || {},
> +    FUNCLIST => $args->{dl_func_list} || [],
> +    IMPORTS  => $args->{dl_imports}   || {},
> +    FILE     => $file_base,
> +  );

Seems like a lot of parameters, and the parameter space is getting a 
bit crowded, but I don't feel like devising anything better right now 
either.

> +sub link_c {
> +  my ($self, $to, $file_base) = @_;
> +  my $cf = $self->{config};
> +
> +  $file_base =~ tr/"//d; # remove any quotes
> +  my $perl_inc = File::Spec->catdir($cf->{archlibexp}, 'CORE'); 
> #location of perl.exp
> +
> +  my $lddlflags = $cf->{lddlflags};
> +  $lddlflags =~ s/\Q$(BASEEXT)\E/$file_base/;
> +  $lddlflags =~ s/\Q$(PERL_INC)\E/$perl_inc/;

I actually got sent a bunch of patches for AIX linking fixes, I should 
make sure they all basically do the same thing before releasing.

Thanks for the help once again.

  -Ken

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

It works to build Pod::Coverage 0.12 on AIX, but the M::B XS test itself
fails.  It only fails two of ten tests, and those are related to
cleanup:

t/xs............ok 8/10Can't remove directory blib/arch/auto/XSTest: Do
not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib/arch/auto: Do not specify an existing file.
at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib/arch: Do not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib: Do not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
# Test 9 got: 'Couldn't remove 'blib': Do not specify an existing file.
' (t/xs.t at line 72)
#   Expected: ''
# Failed test 10 in t/xs.t at line 75
t/xs............FAILED tests 9-10
        Failed 2/10 tests, 80.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------
-------
t/xs.t                    10    2  20.00%  9-10
1 test skipped.
Failed 1/10 test scripts, 90.00% okay. 2/157 subtests failed, 98.73%
okay.

The test code is:

eval {$m->dispatch('realclean')};
ok $@, '';

# Make sure blib/ is gone after 'realclean'
ok not -e 'blib';

So, this may not be the fault of the patch but instead bad assumptions
on
the part of the test.  On the other hand, this same test passed with the
second revision of the patch (the current one being #3 I believe).

It may also be related to me running the test on an NFS mounted homedir.
I tried it on a local disk and it passed.  So, I'm willing to write off
the
failures to the assumptions of the test suite and say it's a good
candidate for
then next release unless someone has an OS/2 or VMS box to pound on it
with.

Thanks to everyone who helped.

-----Original Message-----
From: Randy W. Sims [mailto:Ra...@Th...]=20
Sent: Tuesday, November 18, 2003 8:09 PM
To: mod...@li...
Cc: James.FitzGibbon; Michael G Schwern
Subject: Re: [Module::Build] Problem building XS modules on AIX


On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
> I've updated Randy's patch to find the .exp files in the right place=20
> on AIX, but I don't have the necessary Windows environment to see if=20
> I've broken things there.

I've updated James' update of my patch ;) There were some Windows=20
problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if=20
you don't pass in something for some of the arguments even if its an=20
empty array or hash ref. I also changed it so that it generates the=20
def/exp file in the source directory and put the correct names into=20
add_to_cleanup().

James, can you please run this through the test suite one more time?

Michael, VMS wasn't calling Mksymlists before though it looks like it=20
should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to=20
now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is=20
this correct?

> Perhaps what is needed is to update EU::Mksymlists to both export the=20
> platform-specific extensions as constants and return the canonical=20
> path to the written file back to it's
> caller so that link_c() in M::B can act more intelligently.
>=20
> Thanks.

Seems like a harmless but beneficial change, since the name of the file=20
can vary depending on $^O, and there aught to be some way to find out=20
what it is without read the source.

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Randy W. S. <Ra...@Th...>]

On 11/19/2003 5:48 PM, James.FitzGibbon wrote:

> It works to build Pod::Coverage 0.12 on AIX, but the M::B XS test itself
> fails.  It only fails two of ten tests, and those are related to
> cleanup:
> 
> t/xs............ok 8/10Can't remove directory blib/arch/auto/XSTest: Do
> not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib/arch/auto: Do not specify an existing file.
> at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib/arch: Do not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib: Do not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> # Test 9 got: 'Couldn't remove 'blib': Do not specify an existing file.
> ' (t/xs.t at line 72)
> #   Expected: ''
> # Failed test 10 in t/xs.t at line 75
> t/xs............FAILED tests 9-10
>         Failed 2/10 tests, 80.00% okay
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> ------------------------------------------------------------------------
> -------
> t/xs.t                    10    2  20.00%  9-10
> 1 test skipped.
> Failed 1/10 test scripts, 90.00% okay. 2/157 subtests failed, 98.73%
> okay.
> 
> The test code is:
> 
> eval {$m->dispatch('realclean')};
> ok $@, '';
> 
> # Make sure blib/ is gone after 'realclean'
> ok not -e 'blib';
> 
> So, this may not be the fault of the patch but instead bad assumptions
> on
> the part of the test.  On the other hand, this same test passed with the
> second revision of the patch (the current one being #3 I believe).
> 
> It may also be related to me running the test on an NFS mounted homedir.
> I tried it on a local disk and it passed.  So, I'm willing to write off
> the
> failures to the assumptions of the test suite and say it's a good
> candidate for
> then next release unless someone has an OS/2 or VMS box to pound on it
> with.
> 
> Thanks to everyone who helped.
> 

Ok, so this is likely a problem with delete_filetree in M::B::Base on 
NFS. I no nothing of NFS, so I'll get off at this station...

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Ken W. <ke...@ma...>]

On Wednesday, November 19, 2003, at 04:48  PM, James.FitzGibbon wrote:
> So, this may not be the fault of the patch but instead bad assumptions
> on the part of the test.  On the other hand, this same test passed 
> with the
> second revision of the patch (the current one being #3 I believe).
>
> It may also be related to me running the test on an NFS mounted 
> homedir.
> I tried it on a local disk and it passed.  So, I'm willing to write off
> the failures to the assumptions of the test suite and say it's a good
> candidate for then next release unless someone has an OS/2 or VMS box
> to pound on it with.
>
> Thanks to everyone who helped.

Did this thread result in a patch for M::B?

  -Ken

Re: [Module::Build] Problem building XS modules on AIX

[Randy W. S. <Ra...@Th...>]

Ken Williams wrote:

>
>  On Wednesday, November 19, 2003, at 04:48 PM, James.FitzGibbon
>  wrote:
>
> > So, this may not be the fault of the patch but instead bad
> > assumptions on the part of the test. On the other hand, this same
> > test passed with the second revision of the patch (the current one
> > being #3 I believe).
> >
> > It may also be related to me running the test on an NFS mounted
> > homedir. I tried it on a local disk and it passed. So, I'm willing
> > to write off the failures to the assumptions of the test suite and
> > say it's a good candidate for then next release unless someone has
> > an OS/2 or VMS box to pound on it with.
> >
> > Thanks to everyone who helped.
>
>
>  Did this thread result in a patch for M::B?
>
>  -Ken

No, the previous patch was the best I could do 
<http://sourceforge.net/mailarchive/message.php?msg_id=6567348>, as I 
know nothing of NFS. The reason that this test passed for James at one 
point was because an initial version of the patch got the arguments to 
add_to_cleanup() wrong by not including any directories. When this was 
fixed it created a problem that is, I believe, directly linked with 
M::B's cleanup versus NFS. I.E. AIX is fully supported with the above 
patch, but NFS in general is not and remains an open issue.

Randy.

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

More specifically it doesn't work for my particular AIX
NFS implementation, which is admittedly pretty poorly done.

Given that this works just fine for most of the modules I
tried and only fails for M::B's XSTest subdirectory, I'd say that
the benefits outweigh the downside.

-----Original Message-----
From: Randy W. Sims [mailto:Ra...@Th...]=20
Sent: Friday, November 28, 2003 11:34 AM
To: Ken Williams
Cc: James.FitzGibbon; mod...@li...
Subject: Re: [Module::Build] Problem building XS modules on AIX


Ken Williams wrote:

>
>  On Wednesday, November 19, 2003, at 04:48 PM, James.FitzGibbon
>  wrote:
>
> > So, this may not be the fault of the patch but instead bad=20
> > assumptions on the part of the test. On the other hand, this same=20
> > test passed with the second revision of the patch (the current one=20
> > being #3 I believe).
> >
> > It may also be related to me running the test on an NFS mounted=20
> > homedir. I tried it on a local disk and it passed. So, I'm willing=20
> > to write off the failures to the assumptions of the test suite and=20
> > say it's a good candidate for then next release unless someone has=20
> > an OS/2 or VMS box to pound on it with.
> >
> > Thanks to everyone who helped.
>
>
>  Did this thread result in a patch for M::B?
>
>  -Ken

No, the previous patch was the best I could do=20
<http://sourceforge.net/mailarchive/message.php?msg_id=3D6567348>, as I=20
know nothing of NFS. The reason that this test passed for James at one=20
point was because an initial version of the patch got the arguments to=20
add_to_cleanup() wrong by not including any directories. When this was=20
fixed it created a problem that is, I believe, directly linked with=20
M::B's cleanup versus NFS. I.E. AIX is fully supported with the above=20
patch, but NFS in general is not and remains an open issue.

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Randy W. S. <Ra...@Th...>]

James.FitzGibbon wrote:

>>>Any feedback appreciated.
>>>
> 
> 
>>I'm the one who wrote Windows.pm. Can you post your perl Config.pm. 
>>Other than calling Mksymlists, it looks like we need to do some
> 
> variable 
> 
>>substitutions on some of the $Config variables, and I'll need to see 
>>Config.pm to know which ones.
> 
> 
> I'll spare list bandwidth by sending the config output direct to you.
> 
> I had gotten things a bit closer by copying the technique you use in
> Windows.pm.
> Basically add a prelink_c to M::B::Base with an empty stub and then make
> an AIX platform that tries to do what Windows::prelink_c() does, but the
> variable substitution part is still dogging me.  I presume it's
> something
> similar to your format_compiler_cmd() subroutine as opposed to setting
> something
> in the environment based upon values from Config?
> 
> Thanks.
> 

Sorry to take so long; I had to leave for a meeting. Sounds like you 
mostly had it working. The substitutions where minor as you can see from 
the patch. You might have to tweak this as I don't have AIX to test on; 
in fact I'm doing this on a laptop with no compiler, so I've had to 
parse it mentally, but it should be pretty close.

Let me know if this works.

Thanks,
Randy.