Need to make sure version of machocheck found matches that of the linker

[cooljeanius]

This is from 978cb427433cc9a352c782f5ed368ba56802f569's commit message. I forget what exactly happens if the machocheck version differs from that of the linker's, but presumably it's something bad.

[cooljeanius]

I forget what exactly happens if the machocheck version differs from that of the linker's, but presumably it's something bad.

Right, what happens is that machocheck is unable to recognize the load commands generated by newer linkers, leading to error messages like this:

  CCLD     temacs
ld: warning: option -prebind is obsolete and being ignored
/opt/local/bin/gmkdir -p  ../etc
post-link processing is unnecessary here.
if test "x/opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/machocheck" != "x"; then \
      /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/machocheck -progress temacs; \
    fi
machocheck failed: temacs load command #9 is an unknown kind 0x32 in temacs
make[1]: *** [temacs] Error 1
make: *** [src] Error 2

[cooljeanius]

(note that the "iains" in that path is @iains; I was using his darwin-xtools project)

[iains]

I'm not sure from this what you are trying to achieve. However, it is correct to say that the set of load commands does change over time, and if the linker you are using has one that any other tool does not recognise - that will be the error.

If you are on a version of the OS like 11, or 12, then the latest version of xtools is not likely to work (I have not updated to use the last version of Xcode sources and those are actually rather old too - 12.0 where the tools are up to 13.x).

I am curious about why an end-user package would need a tool that AFAIU is made for testing that the linker et. al. are working correctly.

Edit:

Actually, neither ObjectDump nor machocheck from the ld64- project are included in Xcode (at least so far as the versions i've checked, from 3.1.4 - 13.x), so using machocheck in a build recipe is very non-standard, and introduces a dependency on building a suitable ld64-xxxx project.

otool is available in all versions to inspect mach-o objects. objdump is available in later versions of Xcode.

[cooljeanius]

I'm not sure from this what you are trying to achieve. However, it is correct to say that the set of load commands does change over time, and if the linker you are using has one that any other tool does not recognise - that will be the error.

If you are on a version of the OS like 11, or 12, then the latest version of xtools is not likely to work (I have not updated to use the last version of Xcode sources and those are actually rather old too - 12.0 where the tools are up to 13.x).

I am curious about why an end-user package would need a tool that AFAIU is made for testing that the linker et. al. are working correctly.

So, basically, emacs is weird. It has this "dumping" mechanism where it basically hacks and re-links itself to try to include some of the lisp in the actual executable to improve startup times. This involves fiddling around with some low-level mach-o internals that can lead to invalid mach-o executables if done wrong, as I've encountered in issue #1. (Note that upstream emacs has replaced the old dumping mechanism with a newer "portable dumper", but my fork diverged from upstream long before that, and it'd be too much work to try to merge that feature now)

Edit:

Actually, neither ObjectDump nor machocheck from the ld64- project are included in Xcode (at least so far as the versions i've checked, from 3.1.4 - 13.x), so using machocheck in a build recipe is very non-standard, and introduces a dependency on building a suitable ld64-xxxx project.

Yeah I've got it installed via MacPorts. Also, it's optional, so if there's no machocheck present, the check just won't run. But, if machocheck is present, it should at least do the right thing.