ikiwiki gives 'Bus Error' with perl5.8

[geychaner@…]

I'm trying to run ikiwiki from MacPorts. When I execute:

ikiwiki -setup /opt/local/etc/ikiwiki/auto.setup

it asks for the name of the wiki, and then gives an oh-so-helpful 'Bus error'. The machine in question is an old Core Duo Mini running 10.5.8; the only ports installed are Subversion and ikiwiki.

[geychaner@…]

Fixed (sort of); based on a note on the ikiwiki install page (​http://ikiwiki.info/install/) that ikiwiki doesn't work with perl 5.8, I first installed perl5 with the perl5_10 variant. This seems to solve the immediate problem, though the p5-module-build activation had to be forced.

[jmroot (Joshua Root)]

Please remember to fill in the Port field and cc the maintainer. There would be more information in the crash report, so it's usually helpful to attach it.

[tommyd@…]

I'm working on a solution.

[tommyd@…]

I've added two variants, perl510 and perl512 (the latter is the default) in r71236 which should resolve the issue. Please tell me if it works for you.

[geychaner@…]

failure attempting to install with the perl510 variant

[geychaner@…]

Nope, it's actually wasting time installing perl 5.8.9 when I try to install the perl510 variant. And then it fails with the above install log.

[jmroot (Joshua Root)]

All the modules depend on perl5 which depends on whichever perl version you selected with a variant.

[geychaner@…]

Replying to jmr@…:

All the modules depend on perl5 which depends on whichever perl version you selected with a variant.

The problem seems to be that we want an ikiwiki variant to be able to depend on a *variant* of perl5 (+perl5_10 or +perl5_12), which just doesn't seem to be possible within the MacPorts portfiles. The only way to resolve it seems to be to install perl5 first (selecting the variant you want), and then install ikiwiki.

[geychaner@…]

Installed perl5.10 first, then ikiwiki; failed.

[geychaner@…]

IInstalling perl5 with the +perl5_10 or +perl5_12 variant before installing ikiwiki now fails; the log file (for perl5_10) is attached above. I can't find a way to successfully install ikiwiki with the changes; nothing seems to work. (I suspect the problem is with the "set perl_binary" lines, since the binary for perl5.10 is "perl5.10.1" and likewise for perl5.12.)

[tommyd@…]

Replying to geychaner@…:

IInstalling perl5 with the +perl5_10 or +perl5_12 variant before installing ikiwiki now fails; the log file (for perl5_10) is attached above. I can't find a way to successfully install ikiwiki with the changes; nothing seems to work. (I suspect the problem is with the "set perl_binary" lines, since the binary for perl5.10 is "perl5.10.1" and likewise for perl5.12.)

Actually perl5.10 and perl5.12 should install symlinks from perl5.10.1 to 5.10 and perl5.12.1 to perl5.12. At least these are present for me:

$ ls -l /opt/local/bin/perl*
-rwxr-xr-x  2 root  admin   1,1M 10 Mai  2009 /opt/local/bin/perl
lrwxr-xr-x  1 root  admin     9B 27 Jan  2009 /opt/local/bin/perl5 -> perl5.8.9
lrwxr-xr-x  1 root  admin    25B 12 Sep 01:09 /opt/local/bin/perl5.10 -> /opt/local/bin/perl5.10.1
-rwxr-xr-x  2 root  admin   1,3M  7 Dez  2009 /opt/local/bin/perl5.10.1
lrwxr-xr-x  1 root  admin     9B 12 Sep 01:09 /opt/local/bin/perl5.8 -> perl5.8.9
-rwxr-xr-x  2 root  admin   1,1M 10 Mai  2009 /opt/local/bin/perl5.8.9

I'm also a bit stuck when it comes to provide a "real" fix for this issue - I posted a question on macports-dev (​http://lists.macosforge.org/pipermail/macports-dev/2010-September/012750.html) - but didn't got answers as of now.

The only "hack" I could imagine here is to error out before the port is even fetched as soon as perl5.8 is detected. Another issue might be that only perl5.8 seems to install /opt/local/bin/perl, so other software which just depends on "some" perl version might refuse to work as well.

[geychaner@…]

Replying to tommyd@…:

Replying to geychaner@…:

IInstalling perl5 with the +perl5_10 or +perl5_12 variant before installing ikiwiki now fails; the log file (for perl5_10) is attached above. I can't find a way to successfully install ikiwiki with the changes; nothing seems to work. (I suspect the problem is with the "set perl_binary" lines, since the binary for perl5.10 is "perl5.10.1" and likewise for perl5.12.)

Actually perl5.10 and perl5.12 should install symlinks from perl5.10.1 to 5.10 and perl5.12.1 to perl5.12. At least these are present for me:

Not present on my system after installing perl5 +perl5_10 or perl5 +perl5_12. This only appears if you have multiple versions of perl on your system; take a look at that awful "mangle_names" section of the perl5.10 portfile.

I'm also a bit stuck when it comes to provide a "real" fix for this issue - I posted a question on macports-dev (​http://lists.macosforge.org/pipermail/macports-dev/2010-September/012750.html) - but didn't got answers as of now. The only "hack" I could imagine here is to error out before the port is even fetched as soon as perl5.8 is detected. Another issue might be that only perl5.8 seems to install /opt/local/bin/perl, so other software which just depends on "some" perl version might refuse to work as well.

If you install "perl5 +perl5_10", you get an /opt/local/bin/perl that points to perl5.10.1, and likewise for "perl +perl5_12". What you might want to do is check whether "perl5" points to the selected version of perl, remembering to strip off the minor version number as done in "mangle_names":

set branch [join [lrange [split ${version} .] 0 1] .]

If NOT, then you need to set "perl_binary" to the explicit version. If so, you just use "perl5". (Of course, if someone changes their active perl version after installing ikiwiki, you're really in trouble...). Again, I just don't know how to solve this one properly.

[tommyd@…]

Note that another solution could be to just bug the owner of #16830 enough to make 5.10 (or better 5.12) finally the default and drop the unmaintained 5.8 altogether. (This is in discussion since only two years.) And of course MacPorts still has no proper upgrade path for users of the "old" default port, so some hand work is required to get all the perl modules in the right place:

$ port installed name:^p5- | cut -f 3 -d " " > perl_ports.txt
$ cat perl_ports.txt | xargs sudo port -d -v -f uninstall
$ cat perl_ports.txt | xargs sudo port -d -v -f clean --archive
$ cat perl_ports.txt | xargs sudo port -d -v install

[geychaner@…]

I think the best answer for now is the following: 1) Ditch the perl510 and perl512 variants for ikiwiki. They don't do the right thing; from a clean install they install both 5.1x and 5.8, and install 'perl5' without the proper variant, making perl5.8 the default and installing all the perl modules wrong. 2) In the pre-config stage, check the '/opt/local/bin/perl5' symlink. Proceed only if it already exists and points to a perl > 5.8. Yes, this means 'perl5' has to be installed with the right variant before ikiwiki will install. (Alternatively, if the symlink doesn't exist, you could install perl5 with by doing an ugly 'exec port install perl5 +<variant>') 3) Ditch the 'perl_binary', and assume that after (2) that perl5 will point to a legit version.

[geychaner@…]

My best guess as to what the portfile should look like

[geychaner@…]

I've attached a "best-guess" as to what the ikiwiki portfile should look like. (Sorry about the .txt extension.)

1. The perl variants are named the same as in the perl5 port; they seem to fall through to the 'perl5' dependency if no perl has been installed.

2. The mangle_names variant allows you to install even if you already have a different version of perl installed, again by falling through to the 'perl5.x' dependency. It might not need to be explicitly specified in the ikiwiki Portfile.

3. The post_build finds the requested version of perl for the patching, whether you have one version installed or many.

[geychaner@…]

Fix the portfile revision number; must be an integer. Sigh.

[tommyd@…]

This unfortunately does not work if _any_ of the listed p5-* dependencies have been installed under the non-default perl:

$ ikiwiki
Failed to load plugin IkiWiki::Plugin::recentchanges: Can't locate HTML/Entities.pm in @INC (@INC contains: /opt/local/lib/perl5/site_perl/5.10.1/darwin-2level /opt/local/lib/perl5/site_perl/5.10.1 /opt/local/lib/perl5/site_perl/5.8.9 /opt/local/lib/perl5/site_perl/5.8.8 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl/5.10.1/darwin-2level /opt/local/lib/perl5/vendor_perl/5.10.1 /opt/local/lib/perl5/vendor_perl/5.8.9 /opt/local/lib/perl5/vendor_perl/5.8.8 /opt/local/lib/perl5/vendor_perl /opt/local/lib/perl5/5.10.1/darwin-2level /opt/local/lib/perl5/5.10.1 .) at /opt/local/lib/perl5/vendor_perl/5.8.9/IkiWiki/Plugin/recentchanges.pm line 8.
BEGIN failed--compilation aborted at /opt/local/lib/perl5/vendor_perl/5.8.9/IkiWiki/Plugin/recentchanges.pm line 8.
Compilation failed in require at (eval 29) line 2.
BEGIN failed--compilation aborted at (eval 29) line 2.

So you see two things here:

• The missing dependency is in $prefix/lib/perl5/vendor_perl/5.8.9/darwin-2level, which is (for whatever reason) not in @INC, while a couple of other similar paths are (no, I don't mind to look into the perl5 portfile's path mangling for now, call me ignorant :))
• Since the perl5 setup calls $prefix/bin/perl Makefile.PL, the IkiWiki plugins land in $prefix/lib/perl5/vendor_perl/5.8.9, not the expected / wanted lib/perl5/vendor_perl/5.10.1

I understand that my current version is not working as it should, but I see no easy way to make it work properly with the mess MPs has with its perl version. Since my time I can devote to MP is rather limited, I could imagine two things:

• If you're intested I can make you the maintainer of the port and you can work out the issues in your pace (I have not much use of ikiwiki nowadays anyways)
• I revert the Portfile back to the version without variants and we / you try to work out the perl issues in the auto-setup, for example by patching it so it works with 5.8.x as well
• If the previous thing is too hard to do, we could still bug the perl5 port owners to finally remove / replace the ancient 5.8 version

[geychaner@…]

Replying to tommyd@…:

This unfortunately does not work if _any_ of the listed p5-* dependencies have been installed under the non-default perl: [...]

• The missing dependency is in $prefix/lib/perl5/vendor_perl/5.8.9/darwin-2level, which is (for whatever reason) not in @INC, while a couple of other similar paths are (no, I don't mind to look into the perl5 portfile's path mangling for now, call me ignorant :))

This seems (to me) to be a problem with the perl5 port group. I'd just file a bug against it, with ikiwiki as the exemplar.

• Since the perl5 setup calls $prefix/bin/perl Makefile.PL, the IkiWiki plugins land in $prefix/lib/perl5/vendor_perl/5.8.9, not the expected / wanted lib/perl5/vendor_perl/5.10.1

Would overriding perl5.bin in the portfile fix this problem? That perl version detect code I put in post-patch could easily be moved to pre-fetch and set perl5.bin. If not, then there needs to be a way to override the perl version called by the perl5 setup, and this should be a MacPorts enhancement request.

I understand that my current version is not working as it should, but I see no easy way to make it work properly with the mess MPs has with its perl version. Since my time I can devote to MP is rather limited, I could imagine two things:

• If you're intested I can make you the maintainer of the port and you can work out the issues in your pace (I have not much use of ikiwiki nowadays anyways)

I'd do it, but I've already spent more time with it than I should, and it's ticked me off so much that, since I am only using MacPorts for this one thing, I'm considering bailing and just installing it the hard way (or upgrading the machine to SnowLeopard to get a perl5.10 the easy way). Also, I'm in Chile on a 2MB/s connection, so every uninstall/reinstall test cycle takes me hours. Now that I have something that works, I'm tempted not to muck with it too much.

• I revert the Portfile back to the version without variants and we / you try to work out the perl issues in the auto-setup, for example by patching it so it works with 5.8.x as well
• If the previous thing is too hard to do, we could still bug the perl5 port owners to finally remove / replace the ancient 5.8 version

I think it should be thrown right back at the perl5 port owners. It really, really shouldn't be this hard. Really.

[tommyd@…]

Replying to geychaner@…:

Replying to tommyd@…:

• Since the perl5 setup calls $prefix/bin/perl Makefile.PL, the IkiWiki plugins land in $prefix/lib/perl5/vendor_perl/5.8.9, not the expected / wanted lib/perl5/vendor_perl/5.10.1

Would overriding perl5.bin in the portfile fix this problem? That perl version detect code I put in post-patch could easily be moved to pre-fetch and set perl5.bin. If not, then there needs to be a way to override the perl version called by the perl5 setup, and this should be a MacPorts enhancement request.

I tried that locally but the first thing I noticed is that overwriting perl5.bin within a variant is not acknowledged anywhere (either before the perl5 setup call nor afterwards). I think I remember that variants are executed a little differently from the rest of the code of a portfile - anyways, what I ended up locally was overwriting configure.cmd which had the incorrect perl5 binary. Then of course the ikiwiki files would land in the correct perl version - if the installation itself would go through even! Again, the problem are missing packages there.

I understand that my current version is not working as it should, but I see no easy way to make it work properly with the mess MPs has with its perl version. Since my time I can devote to MP is rather limited, I could imagine two things:

• If you're intested I can make you the maintainer of the port and you can work out the issues in your pace (I have not much use of ikiwiki nowadays anyways)

I'd do it, but I've already spent more time with it than I should, and it's ticked me off so much that, since I am only using MacPorts for this one thing, I'm considering bailing and just installing it the hard way (or upgrading the machine to SnowLeopard to get a perl5.10 the easy way). Also, I'm in Chile on a 2MB/s connection, so every uninstall/reinstall test cycle takes me hours. Now that I have something that works, I'm tempted not to muck with it too much.

Right, while I have a slightly better connection, I am still used to trigger all my install tasks with the infamous -n option... also because I'm still on an early core 2 duo and not on one of these fancy i5 / i7 machines.

• I revert the Portfile back to the version without variants and we / you try to work out the perl issues in the auto-setup, for example by patching it so it works with 5.8.x as well
• If the previous thing is too hard to do, we could still bug the perl5 port owners to finally remove / replace the ancient 5.8 version

I think it should be thrown right back at the perl5 port owners. It really, really shouldn't be this hard. Really.

Right, that is what I am thinking of as well. I had a similar nightmare for a python-based ports where the situation with all the different py24-*, py25-* and py26-* ports is even worse. It would all be much, much easier if people like me wouldn't fear upgrading so much and we could just use binary packages.

[geychaner@…]

Replying to tommyd@…:

Replying to geychaner@…:

Would overriding perl5.bin in the portfile fix this problem?

[...] overwriting configure.cmd which had the incorrect perl5 binary. Then of course the ikiwiki files would land in the correct perl version - if the installation itself would go through even! Again, the problem are missing packages there.

Ok, so we have a fix for one of the two problems; modifying the portfile will allow ikiwiki to go to the right place. Take that code I stuck in post-patch and stick it in pre-configure, and have it set "configure.bin". I still think the "modules not in @INC" problem is really a perl problem, not an ikiwiki problem.

I'd do it, but I've already spent more time with it than I should...I'm in Chile on a 2MB/s connection, so every uninstall/reinstall test cycle takes me hours.

Right, while I have a slightly better connection, I am still used to trigger all my install tasks with the infamous -n option... also because I'm still on an early core 2 duo and not on one of these fancy i5 / i7 machines.

Got you beat there; mine is an original Core Duo.

I think it should be thrown right back at the perl5 port owners. It really, really shouldn't be this hard. Really.

Right, that is what I am thinking of as well. I had a similar nightmare for a python-based ports where the situation with all the different py24-*, py25-* and py26-* ports is even worse. It would all be much, much easier if people like me wouldn't fear upgrading so much and we could just use binary packages.

I agree; Python is just as bad. I have 3 pythons on my system: the Mac OS X default, the one Scisoft installed in /Applications/scisoft, and the one Plone (or maybe Trac) installed somewhere in /usr/local (but not /usr/local/bin). Which one you get depends on your $PATH, and they each have a different module subset installed.

[tommyd@…]

As this is all just so bit-rotten, I went the very easy route now for r72409:

• remove the variants as they didn't do the right thing anyways
• check that $prefix/bin/perl is at least at 5.10 or higher
• if not, error out and abort the installation while giving the user a rough overview of the pain he has to go through in order to get it to run

I close this for now.