Bug #5849 for Module-Install: load_extensions() causes "Subroutine %s redefined" warnings

Wed Mar 31 04:49:07 2004 shay [...] cpan.org - Ticket created

Subject:

load_extensions() causes "Subroutine %s redefined" warnings

I've created a module that uses a pair of "private extension" modules, Module::Install::PRIVATE and Module::Install::PRIVATE::Foo. The latter one inherits from the former one, which in turn inherits from Module::Install::Base. Each extension has a method with a suitably "unique" name such that the autoloader will correctly find it. These methods simply return the object on which they were invoked, and the object can then be used to invoke further methods on (which perhaps have less "unique" names and which could not therefore be reliably found by the autoloader). An example of this setup is in the attached "Foo.tar.gz" archive. You will note that running "perl Makefile.PL" produces two "Subroutine %s redefined" warnings: Subroutine get_private_obj redefined at inc/Module/Install/PRIVATE.pm line 6. Subroutine greeting redefined at inc/Module/Install/PRIVATE.pm line 7. I believe that the reason for this is that inc/Module/Install/PRIVATE.pm gets loaded once (by load_extensions()) in the course of looking for get_private_mymodule_obj(), and then again (by inc/Module/Install/PRIVATE/Foo.pm) when it is finally located. The reason that inc/Module/Install/PRIVATE/Foo.pm loads inc/Module/Install/PRIVATE.pm even though it has already been loaded is that load_extensions() removed the entry for that file from %INC, so Perl "forgets" that is has already been loaded. This is what causes the warnings. Is there any particular reason why load_extensions() removes entries from %INC? If not, then the following patch (against 0.33) fixes this problem. It certainly works fine for me: --- lib/Module/Install.pm.orig 2004-03-11 12:55:22.000000000 +0000 +++ lib/Module/Install.pm 2004-03-31 10:29:25.758297000 +0100 @@ -265,7 +265,7 @@ next if $self->{pathnames}{$pkg}; eval { require $file; 1 } or (warn($@), next); - $self->{pathnames}{$pkg} = delete $INC{$file}; + $self->{pathnames}{$pkg} = $INC{$file}; push @{$self->{extensions}}, $pkg->new( _top => $top_obj ); } } End of Patch. There are also some similar deletions in Module::Install::import(), with the comment "Unregister loader and worker packages so subdirs can use them again". I haven't actually seen any problems from this, but I wonder if it might have the same problem again? This is all running with Perl 5.8.3 on WinXP. Cheers, - Steve

Download Foo.tar.gz
application/x-gzip 2.2k

Message body not shown because it is not plain text.

Thu Feb 23 04:21:08 2006 adamk [...] cpan.org - Correspondence added

Is this bug still occuring?

Thu Feb 23 04:21:09 2006 The RT System itself - Status changed from 'new' to 'open'

Thu Feb 23 04:41:12 2006 shay [...] cpan.org - Correspondence added

On Thu Feb 23 04:21:08 2006, ADAMK wrote: Show quoted text

> Is this bug still occuring?

Yes. I just retried with perl-5.8.8 and Module-Install-0.56. (I replaced the Module-Install components in the sample Foo.tar.gz with the updated versions to try this.) I still get the warnings, and for the same reason. The same fix still applies. In the real world, a module that I have working with this class hierarchy avoids the warning by having the Module::Install::PRIVATE::Foo subclass not load its parent class (Module::Install::PRIVATE) since it has already been loaded by Module::Install::load_extensions(). However, that is clearly an implementation detail that my subclass should not be relying on, and will break if Module::Install is ever rewritten in such a way that this no longer happens. Any subclass should always ensure that its parent class is loaded. If it is already loaded then this will just be a no-op, but only if the entry for the parent class is still in %INC!

Tue Apr 06 10:35:03 2010 ishigaki [...] cpan.org - Correspondence added

Hi. Applied other patch in the trunk, and will be fixed in the next release. Thanks. On 2004-3-31 Wed 04:49:07, SHAY wrote: Show quoted text

> I've created a module that uses a pair of "private extension" modules, > Module::Install::PRIVATE and Module::Install::PRIVATE::Foo. The > latter one inherits from the former one, which in turn inherits > from Module::Install::Base. > > Each extension has a method with a suitably "unique" name such that > the autoloader will correctly find it. These methods simply return > the object on which they were invoked, and the object can then be > used to invoke further methods on (which perhaps have less "unique" > names and which could not therefore be reliably found by the > autoloader). > > An example of this setup is in the attached "Foo.tar.gz" archive. > > You will note that running "perl Makefile.PL" produces two "Subroutine > %s redefined" warnings: > > Subroutine get_private_obj redefined at inc/Module/Install/PRIVATE.pm > line 6. > Subroutine greeting redefined at inc/Module/Install/PRIVATE.pm line 7. > > I believe that the reason for this is that > inc/Module/Install/PRIVATE.pm gets loaded once (by > load_extensions()) in the course of looking for > get_private_mymodule_obj(), and then again (by > inc/Module/Install/PRIVATE/Foo.pm) when it is finally located. > > The reason that inc/Module/Install/PRIVATE/Foo.pm loads > inc/Module/Install/PRIVATE.pm even though it has already been > loaded is that load_extensions() removed the entry for that file > from %INC, so Perl "forgets" that is has already been loaded. This > is what causes the warnings. > > Is there any particular reason why load_extensions() removes entries > from %INC? > > If not, then the following patch (against 0.33) fixes this problem. > It certainly works fine for me: > > --- lib/Module/Install.pm.orig 2004-03-11 12:55:22.000000000

+0000 Show quoted text

> +++ lib/Module/Install.pm 2004-03-31 10:29:25.758297000 +0100 > @@ -265,7 +265,7 @@ > next if $self->{pathnames}{$pkg}; > > eval { require $file; 1 } or (warn($@), next); > - $self->{pathnames}{$pkg} = delete $INC{$file}; > + $self->{pathnames}{$pkg} = $INC{$file}; > push @{$self->{extensions}}, $pkg->new( _top => $top_obj ); > } > } > End of Patch. > > There are also some similar deletions in Module::Install::import(), > with the comment "Unregister loader and worker packages so subdirs > can use them again". I haven't actually seen any problems from > this, but I wonder if it might have the same problem again? > > This is all running with Perl 5.8.3 on WinXP. > > Cheers, > - Steve

Tue Apr 06 10:35:07 2010 ishigaki [...] cpan.org - Status changed from 'open' to 'patched'

Sun May 09 22:50:09 2010 ishigaki [...] cpan.org - Correspondence added

Hi. Module::Install 0.96/0.97 with a fix is out. Thanks.

Sun May 09 22:50:12 2010 The RT System itself - Status changed from 'patched' to 'open'

Sun May 09 22:50:13 2010 ishigaki [...] cpan.org - Status changed from 'open' to 'resolved'