Haxelib binary broken since updating to 4.3.4-2

Description:

The haxelib binary is broken in the latest version of the package (4.3.4-2):

% haxelib
NekoVM 2.4.0 (c)2005-2023 Haxe Foundation
  Usage : neko <file>
% haxelib help
Uncaught exception - load.c(181) : Module not found : help
% md5sum /usr/bin/haxelib /usr/bin/neko
69e5eb20a4acddbaf868489b7da91c42  /usr/bin/haxelib
69e5eb20a4acddbaf868489b7da91c42  /usr/bin/neko

It is identical to the neko executable and all haxelib functionality has been removed.

The previous version I used was 4.3.3-1 and that worked without issues.

Additional info:

The way the binary has been created until now has always been hacky, and it looks like our luck with this hack finally ran out and it's stopped working on Arch Linux (other distros work fine). This problem does not get caught in the check() stage because at that point the haxelib binary is still intact. At some point after package(), the packaging process now does some manipulation of the haxelib binary which breaks it. Another Haxe user I was debugging this with discovered that running objcopy on a working haxelib executable breaks it in the same way.

Perhaps there is a way to disable whatever is going on during packaging that causes this to happen, but I think it would be better and more secure if the executable were created properly instead of using the hack. I'm working on an upstream fix for this issue: https://github.com/HaxeFoundation/haxe/pull/11653. This link also includes a more in depth explanation of what the problem is with the way the binary is created.

Steps to reproduce:

  1. Confirm that a regular haxelib command does not work: haxelib version
  2. Confirm that the binaries are identical: md5sum /usr/bin/haxelib /usr/bin/neko
Edited by Tobi Laskowski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information