Re: What am I doing wrong? A bad end-user experience

On 9/10/26 04:48, Paul "LeoNerd" Evans wrote:
> I keep a bunch of perl modules in my $HOME:
> 
>    $ env | grep PERL
>    PERL5LIB=/home/leo/lib/perl5
>    PERL_MB_OPT=--install_base=/home/leo
>    PERL_MM_OPT=INSTALL_BASE=/home/leo
> 
> I use system perl.
> 
> Today, I ran some debian updates that jumped from perl 5.40 to 5.42.
> Now, nothing is usable:
> 
>    $ eachperl list
>    Perl API version v5.40.0 of Object::Pad does not match v5.42.0 at
>    /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 218.
>    ...
> 
> OK, fair enough. I guess I need to rebuild Object::Pad:
> 
>    $ cd Object-Pad
> 
>    $ perl Build.PL
>    Attempt to reload Scalar/Util.pm aborted.
>    Compilation failed in require at
>    /usr/lib/x86_64-linux-gnu/perl-base/File/Temp.pm line 153.
>    ...
> 
> Oops. Turns out the Scalar::Util that I have in $HOME/lib/perl5 is
> wrong. No matter, I can just update and install that, right..?
> 
>    $ cpan Scalar::Util
>    Attempt to reload Scalar/Util.pm aborted.
>    Compilation failed in require at /usr/share/perl/5.42/Safe.pm line 4.
> 
> Uhhm. OK.. How do I get out of this one?
> ...


I believe this is a consequence of what I call the "module circular 
dependency problem".  In the simplest case:

* Module A depends upon module B.

* Module B depends upon module A.


Of course, the loop can include more than two modules:  A -> B -> C -> 
... -> A.


And, there can be multiple and/or intertwined loops:  A -> ... -> M -> 
... -> A in parallel with X -> ... -> M -> ... -> X, etc..


When I do any of the above, Perl usually breaks.  I must pay careful 
attention to my programs and modules to avoid circular loops.


But when circular loops are unavoidable, the only reliable solution that 
I have found is to aggregate all of the involved code into one entity. 
This becomes unwieldy as I add more code; especially when some of my 
testing is O(N**2).  I have not attempted this with modules written by 
other people.


I do not know if or how the Perl core modules are checked for circular 
dependencies,  And, if detected, how breakage is prevented.


CPAN is another matter, but seems to be the OP's situation.


Looking for a root cause, AIUI Perl processes a program in two phases: 
compile and run.  Contrast that with the three-phases of, say, the C 
programming language: compile, link, and run.  By separating modules 
into specification and implementation via header and source files, the 
compiler can process one source file at a time in isolation from all 
other source files.  Only internal symbols must be resolved.  Resolution 
of external symbols can be delayed by forwarding their information into 
the object file.  When the linker receives all of the object files, all 
of the symbols are resolvable and the linker can create an executable. 
The three-phase design precluded circular dependencies between source 
files.  But, circular dependencies between header files is still 
possible.  Circular dependencies within the executable are features or 
bugs of that executable, not of the tool chain.


Does it make any sense to ask if a link phase can be added into Perl? 
Is a link phase mutually impossible with some key trait of Perl, such as 
dynamicism?


David