neko 2.1.0

[andyli]

It has just been released and is available at http://nekovm.org/download.

[MikeMcQuaid]

Test and bottling failures here unfortunately.

[apjanke]

Failed build here.

        ==> Determining neko bottle revision...
==> Bottling neko-2.1.0.yosemite.bottle.tar.gz...
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: the __LINKEDIT segment does not cover the end of the file (can't be processed) in: /usr/local/Cellar/neko/2.1.0/bin/nekoc
Error: undefined method `write' for nil:NilClass
Please report this bug:
    https://git.io/brew-troubleshooting
/usr/local/Library/Homebrew/cmd/bottle.rb:258:in `block (2 levels) in bottle_formula'
/usr/local/Library/Homebrew/utils.rb:481:in `ignore_interrupts'
/usr/local/Library/Homebrew/cmd/bottle.rb:257:in `ensure in block in bottle_formula'
/usr/local/Library/Homebrew/cmd/bottle.rb:257:in `block in bottle_formula'
/usr/local/Library/Homebrew/keg.rb:245:in `block in lock'
/usr/local/Library/Homebrew/formula_lock.rb:29:in `with_lock'
/usr/local/Library/Homebrew/keg.rb:241:in `lock'
/usr/local/Library/Homebrew/cmd/bottle.rb:193:in `bottle_formula'
/usr/local/Library/Homebrew/cmd/bottle.rb:410:in `block in bottle'
/usr/local/Library/Homebrew/cmd/bottle.rb:409:in `each'
/usr/local/Library/Homebrew/cmd/bottle.rb:409:in `bottle'
/usr/local/Library/brew.rb:87:in `<main>'

Looks like the neko build might need header name padding? That can be done by passing -headerpad_max_install_names to the linker. See shapelib or search this repo for "headerpad" for examples. You wouldn't have encountered this locally since local builds don't normally have a bottling step.

And then it looks like brew bottle has an internal bug where its cleanup code is referencing a possibly-unitialized variable. That's on us, and it should go away here once the header padding is fixed.

That test failure looks like it might just be a result of the link rewriting failure that's causing the bottle step to fail. Try fixing the header padding and see if it goes away.

[andyli]

The binary that has issue with install_name_tool, nekoc, is not created by a C compiler. It is in fact created by the nekotools boot command, which combines the neko vm binary with a chunk of neko bytecode. It doesn't "fix" the Mach-O header so it would be invalid in the eye of install_name_tool, but it will just work fine.

I guess the use of install_name_tool is to make the executables relocatable? Can it be skipped for now, e.g. to create non-relocatable bottles, until the issue has been fixed upstream?

[MikeMcQuaid]

We don't have any current mechanism to do that skipping; we we install_name_tool for more than just relocatable bottles, unfortunately.

[UniqMartin]

I guess the use of install_name_tool is to make the executables relocatable? Can it be skipped for now, e.g. to create non-relocatable bottles, until the issue has been fixed upstream?

We cannot create non-relocatable bottles, but what we can do is disable bottle creation, effectively forcing every Homebrew user of neko to build the formula from source. This might be a viable option to get this version out before the upstream issue is fixed. This would mean replacing the bottle do block with:

# Remove when resolved: https://github.com/HaxeFoundation/neko/issues/130
bottle :disable, "Neko binaries cannot be edited with 'install_name_tool'."

However, that's something we do extremely rarely and I'm not sure other maintainers will approve.

---

Sadly, there's another breaking (and unrelated) issue with 2.1.0: Libraries are installed to #{prefix}/lib and binaries to #{prefix}/bin. The latter link to @rpath/libneko.2.dylib and have an embedded RPATH of @executable_path/ so none of the binaries actually work out of the box.

[MikeMcQuaid]

However, that's something we do extremely rarely and I'm not sure other maintainers will approve.

Yeh, I'd rather see us stick on an old version than do that, personally.

[UniqMartin]

Any reason not to use the GitHub release tarball https://github.com/HaxeFoundation/neko/archive/v2-1-0.tar.gz instead? We prefer that for tagged releases instead of making every user do a Git clone.

[andyli]

Just revised the formula to use the tarball from http://nekovm.org/. It was created by git archive, so it should be the same as the Github one.

[andyli]

I have just used a workaround to avoid using nekotools boot to build binaries. The detail is explained in HaxeFoundation/neko#130 (comment).

For @executable_path/, it was used because the binary archive distributed in http://nekovm.org/download is using a flat directory structure. I've turned it off with -DRELOCATABLE=OFF now to let homebrew handle it.

[andyli]

The test now failed with

failed: brew readall --aliases --syntax
Stacktrace

        /usr/local/Library/Homebrew/cmd/pull.rb:555: warning: possibly useless use of a variable in void context

Any idea?

[UniqMartin]

This was a silly mistake on our side that has since been resolved and isn't caused by your build. Thanks for fixing the problem upstream!

Merged in 8292d2e. Thank you for this contribution to Homebrew, @andyli! 🎉

[UniqMartin]

@andyli FYI, c512ffa – Sorry I missed that in my final review of this PR.

[andyli]

@UniqMartin ah! Thanks for fixing that!