Peculiar perl version issue

Ryan Schmidt ryandesign at macports.org
Wed Jun 12 19:06:08 UTC 2019


On Jun 12, 2019, at 13:41, Bruce R Miller wrote:

> On 6/12/19 1:14 PM, Ryan Schmidt wrote:
>> On Jun 12, 2019, at 10:26, Bruce Miller wrote:
>> 
>>> So, apparently the perl portgroup replaces shebang
>>> lines that it recognizes with a call to the specific
>>> perl that was specified in the portfile (? is that right?)
>>> And if so, it doesn't recognize the above line,
>>> so it leaves it alone.
>> I can't find any code in the perl5 portgroup that replaces shebang lines. But if you need to do that, it's easy to write an fs-traverse/reinplace loop to do so. Many other ports do something like that, so you can probably find a few lines of code in another portfile that you can copy and paste.
> 
> Seems like it would have to do something like that.
> The normal approach for an executable perl script
> would be
>  #!/usr/bin/perl -w
> and that would fail under macports for exactly the
> same reasons as env perl does.

Of course. I don't know much about how perl modules build or solve this problem generally. Somehow they just work. I don't think we're doing anything special in MacPorts. Maybe there is a magic value that source files use there, which gets replaced by the perl build system.


> But, given your clue, I poked around and found this in
> cpan2port's Portfile:
> configure {
>    reinplace "s|#! /usr/bin/env perl|#!${prefix}/bin/perl${perl5.major}|g" ${worksrcpath}/${name}
> }
> 
> I'm not much of a tcl programmer, but it looks close to what
> I'm looking for... just need to loop over the executables...

...using fs-traverse and maybe some filename inspection. fs-traverse is not described in the MacPorts guide yet but is described in `man portfile` and you can find examples in other portfiles.


>>> Since LaTeXML specifies perl 5.26 (Yes, I know
>>> I need to update it, but that's only a shortterm fix),
>>> and macports is installing both 5.26 and 5.28,
>>> all of LaTeXML's modules go under
>>>  /opt/local/lib/perl5/vendor_perl/5.26
>>> and env perl -v shows
>>>  This is perl 5, version 28...
>> FYI, env perl -v shows version 5.28 because you have installed the perl5 port with the +perl5_28 variant. But a user might install it with a different variant and then env perl -v would be a different version for them. Point being: you can't rely on "perl" being a particular version on a user's system.
> 
> Yep, exactly.  As long as LaTeXML's modules are installed version specific,

They are. My understanding is that all perl modules are.


> and if there's multiple perls, it's a crapshoot whether env perl gives you
> the "right" one.
> 
> BTW, I didn't explicitly install *any* perl; This was a fresh install on
> a new mac: basically install XCode, cmdline tools, macports, selfupgrade
> and then port install LaTeXML (+MacTeX).  So I got 5.26 because of LaTeXML,
> and 5.28 apparently for free.

From `port rdeps LaTeXML` we can see that LaTeXML eventually depends on libunistring which requires perl but doesn't care what version (i.e. because it doesn't use any third-party modules) and so it depends on the perl5 port. The perl5 port's default variant was recently changed from +perl5_26 to perl5_28, meaning that it will now pull in the perl5.28 port. If you don't want that, you can install perl5 with the +perl5_26 variant.




More information about the macports-dev mailing list