a.pl

#!/usr/bin/perl
use warnings;
use strict;

use lib '.';

use MyModule;

MyModule::call();
[download]

MyModule.pm

package MyModule;
use warnings;
use strict;

sub call {
    MyModule2::authorize();
}

__PACKAGE__
[download]

MyModule2.pm

package MyModule2;
use warnings;
use strict;

sub authorize {
    print "auth\n";
}

__PACKAGE__
[download]

Running ./a.pl results in the following error:

Undefined subroutine &MyModule2::authorize called at MyModule.pm line 
+6.
[download]

Update: It starts working when I include

use MyModule2;
[download]

SSCCE ?

Did you use strict and warnings in all modules?

What if you call Perl with -W switch?

And please don't name different threads with the same title.

Either keep both posts in the same thread or come up with better titles.

Get a log in, so you can fix it next time.

1. If module A uses something from module B, then there OUGHT TO BE use B; inside A.pm. Fullstop. Modules should not expect someone else to load their dependencies for them. There is no need to "optimize" and use a module just one. Perl is clever enough to notice the module had already been loaded and it doesn't load it twice.
   The second time Perl only calls the module's import() subroutine to allow it to export the default list of functions into the calling namespace.
2. You are NOT supposed to run modules directly. Very few modules support that and likely even fewer should.
3. Modules and namespaces are related, but they are NOT the same thing. You can have several namespaces right inside your a.pl script and define the myModule2:authorize right there. It's actually quite common for modules to contain several namespaces. One of them SHOULD match the name of the file, but there's often several others inside.

The following is wrong:

perl MyModule.pm
[download]

To load a module, use

perl -I . -e'use MyModule;'
[download]

"wrong" in the sense of "why would anybody do this?", yes, but not "syntactically wrong" or "won't work" - see my other reply

Can cause problems. They're not equivalent, and the latter is how the module is normally loaded.

Just because I (and they, obviously ;-)) don't know a legitimate reason to use modulinos and the like

Though modulinos are too sneaky/clever for my tastes ("scripts should use modules, not pretend to be modules"), they do have some well-respected fans, led by their illustrious inventor brian_d_foy, as described in more detail at modulino References.

My preference is keep my script mainlines as short as is practicable, with all the heavy lifting done in (unit-tested) module/s.

👁️🍾👍🦟