mercurial @2.8 build failure on 10.9

[petr.fischer@…]

:info:build generating mercurial/locale/da/LC_MESSAGES/hg.mo from i18n/da.po
:info:build msgfmt -v -o mercurial/locale/da/LC_MESSAGES/hg.mo i18n/da.po -c
:info:build error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.8" but "10.9" during configure
:info:build make: *** [build] Error 1
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_mercurial/mercurial/work/2.8'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_mercurial/mercurial/work/2.8" && make -j4 -w all PYTHON=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
:info:build Exit code: 2
:error:build org.macports.build for port mercurial returned: command execution failed
:debug:build Error code: CHILDSTATUS 45012 2
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for mercurial: org.macports.activate org.macports.build org.macports.destroot org.macports.install

[ryandesign (Ryan Carsten Schmidt)]

It builds fine for me on Mavericks. Please "sudo port clean mercurial" and try again and then attach the main.log file if it fails again.

[petr.fischer@…]

Still with error (after port clean...):

:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hg.1 > hg.1.txt.tmp
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hg.1.gendoc > hg.1.gendoc.txt.tmp
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py common > common.txt.tmp
:info:build running build
:info:build running build_mo
:info:build creating mercurial/locale
:info:build creating mercurial/locale/da
:info:build creating mercurial/locale/da/LC_MESSAGES
:info:build generating mercurial/locale/da/LC_MESSAGES/hg.mo from i18n/da.po
:info:build msgfmt -v -o mercurial/locale/da/LC_MESSAGES/hg.mo i18n/da.po -c
:info:build error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.8" but "10.9" during configure
:info:build make: *** [build] Error 1
:info:build make: *** Waiting for unfinished jobs....
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hgignore.5 > hgignore.5.txt.tmp
:info:build mv hg.1.txt.tmp hg.1.txt
:info:build mv common.txt.tmp common.txt
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hgignore.5.gendoc > hgignore.5.gendoc.txt.tmp
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hgrc.5 > hgrc.5.txt.tmp
:info:build mv hgignore.5.txt.tmp hgignore.5.txt
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hgrc.5.gendoc > hgrc.5.gendoc.txt.tmp
:info:build mv hgrc.5.txt.tmp hgrc.5.txt
:info:build mv hgignore.5.gendoc.txt.tmp hgignore.5.gendoc.txt
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst hgmanpage  --halt warning \
:info:build       --strip-elements-with-class htmlonly hgignore.5.txt hgignore.5
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst html  --halt warning \
:info:build       --link-stylesheet --stylesheet-path style.css hgignore.5.txt hgignore.5.html
:info:build mv hgrc.5.gendoc.txt.tmp hgrc.5.gendoc.txt
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst hgmanpage  --halt warning \
:info:build       --strip-elements-with-class htmlonly hgrc.5.txt hgrc.5
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst html  --halt warning \
:info:build       --link-stylesheet --stylesheet-path style.css hgrc.5.txt hgrc.5.html
:info:build mv hg.1.gendoc.txt.tmp hg.1.gendoc.txt
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst hgmanpage  --halt warning \
:info:build       --strip-elements-with-class htmlonly hg.1.txt hg.1
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 runrst html  --halt warning \
:info:build       --link-stylesheet --stylesheet-path style.css hg.1.txt hg.1.html
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_mercurial/mercurial/work/2.8/doc'
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_mercurial/mercurial/work/2.8'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_mercurial/mercurial/work/2.8" && make -j4 -w all PYTHON=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
:info:build Exit code: 2
:error:build org.macports.build for port mercurial returned: command execution failed
:debug:build Error code: CHILDSTATUS 49683 2
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for mercurial: org.macports.activate org.macports.build org.macports.destroot org.macports.install

[seanfarley (Sean Farley)]

Replying to petr.fischer@…:

Still with error (after port clean...):

:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hg.1 > hg.1.txt.tmp
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py hg.1.gendoc > hg.1.gendoc.txt.tmp
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 gendoc.py common > common.txt.tmp
:info:build running build
:info:build running build_mo
:info:build creating mercurial/locale
:info:build creating mercurial/locale/da
:info:build creating mercurial/locale/da/LC_MESSAGES
:info:build generating mercurial/locale/da/LC_MESSAGES/hg.mo from i18n/da.po
:info:build msgfmt -v -o mercurial/locale/da/LC_MESSAGES/hg.mo i18n/da.po -c
:info:build error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.8" but "10.9" during configure
:info:build make: *** [build] Error 1
:info:build make: *** Waiting for unfinished jobs….

This error (and the fact that the buildbot and Ryan have no problems) makes me think this is possibly an upgrade error?

[petr.fischer@…]

It's new clean install (sudo port install mercurial) on the latest macports 2.2.1 base.

[gallafent]

I also hit this problem with a fresh install on a clean 10.9 machine (although for me the mismatch is between 10.6 and 10.9, since I have added the following line in my macports.conf):

macosx_deployment_target 10.6

How may one get the deployment target set correctly to match during the configure and build phases for all ports? I suspect this might be related to #41783 and/or #41321 …

The manual reads:

     macosx_deployment_target
         Value for MACOSX_DEPLOYMENT_TARGET environment variable when invoking the configure script.
         Type: optional
         Default: (current OS version)
         Example:
               macosx_deployment_target 10.4

… but the error in mercurial's build log indicates that this variable in macports.conf is being set correctly during the build phase, but not during the configure phase.

[gallafent]

Cc Me!

[gallafent]

OK, here's the cause and a workaround:

The binary packages of MacPorts appear to be built with macosx_deployment_target 10.9 (or, I guess, not set at all). The value of macosx_deployment_target set globally in /opt/local/etc/macports.conf is not checked when downloading a binary package.

The workaround is to force building from source, and rebuild your installed ports. Detils are given in the bug I just opened for that problem: #41796 … works for me!

[ryandesign (Ryan Carsten Schmidt)]

Why would you set macosx_deployment_target to any value in MacPorts, much less "10.4"? The only reason to change macosx_deployment_target is if you plan to build software on a newer machine and then be able to run it on an older machine, but that's not a use case MacPorts is well-designed for, and in any case trying to build software on 10.9 and then be able to run it on 10.4 is not likely to succeed.

[gallafent]

Replying to ryandesign@…:

Why would you set macosx_deployment_target to any value in MacPorts, much less "10.4"?

Because It's There™ :)

More seriously: you'd set it in order to (exactly as you say) build macports packages on 10.9 which are able to work on an older OS version. I agree that 10.4 would be unlikely to work! 10.6 should work fine though I think (though it remains to be seen, I'm experimenting). That's what the MACOSX_DEPLOYMENT_TARGET is for, and it does work pretty well in my experience! Macports aside, building software on 10.9 which should run on anything 10.6 or later is a pretty standard thing to do, surely.

The only reason to change macosx_deployment_target is if you plan to build software on a newer machine and then be able to run it on an older machine, but that's not a use case MacPorts is well-designed for

What is the MacPorts variable macosx_deployment_target for, then? If it doesn't work, should it not simply be removed? I'm not asking to be difficult, just can't see a use case for it except that. (And please don't remove it, I'm using it, and I'm clearly not the only one … and it does in fact appear to work well for this purpose so far, even if macports wasn't well-designed to support it! :)

and in any case trying to build software on 10.9 and then be able to run it on 10.4 is not likely to succeed.

10.4 no, I agree, that's unlikely to work, it's really too old and the Apple tools don't support it as well I think. It might though (x86 architecture only, not x86-64, and certainly not ppc or ppc64 since recent Xcodes can't target those) … but in any case 10.6 should be fine. That's what the MACOSX_DEPLOYMENT_TARGET environment variable (and the -mmacosx-version-min compiler flags …) are for, isn't it?

Incidentally, I think it's possible that the originator of this bug /had/ upgraded his machine from 10.8 to 10.9, his “clean install” iin comment 4 was only of mercurial, and this problem might appear if macports hadn't been upgraded properly after the OS upgrade.

[seanfarley (Sean Farley)]

Replying to william@…:

Replying to ryandesign@…:

Why would you set macosx_deployment_target to any value in MacPorts, much less "10.4"?

Because It's There™ :)

More seriously: you'd set it in order to (exactly as you say) build macports packages on 10.9 which are able to work on an older OS version. I agree that 10.4 would be unlikely to work! 10.6 should work fine though I think (though it remains to be seen, I'm experimenting). That's what the MACOSX_DEPLOYMENT_TARGET is for, and it does work pretty well in my experience! Macports aside, building software on 10.9 which should run on anything 10.6 or later is a pretty standard thing to do, surely.

Standard for projects that are distributing their own binaries, sure. Which is what MacPorts does.

The only reason to change macosx_deployment_target is if you plan to build software on a newer machine and then be able to run it on an older machine, but that's not a use case MacPorts is well-designed for

What is the MacPorts variable macosx_deployment_target for, then? If it doesn't work, should it not simply be removed? I'm not asking to be difficult, just can't see a use case for it except that. (And please don't remove it, I'm using it, and I'm clearly not the only one … and it does in fact appear to work well for this purpose so far, even if macports wasn't well-designed to support it! :)

and in any case trying to build software on 10.9 and then be able to run it on 10.4 is not likely to succeed.

10.4 no, I agree, that's unlikely to work, it's really too old and the Apple tools don't support it as well I think. It might though (x86 architecture only, not x86-64, and certainly not ppc or ppc64 since recent Xcodes can't target those) … but in any case 10.6 should be fine. That's what the MACOSX_DEPLOYMENT_TARGET environment variable (and the -mmacosx-version-min compiler flags …) are for, isn't it?

It seems there's a confusion between MacPorts and the compiler flag. The compiler flag is useful and provided by Apple for obvious reasons: a (stand-alone) project wants to distribute a binary that works with 10.X SDK. Fair enough. The MacPorts variable exists to pass this value down to the compiler. Only a handful of ports (~20) even use this variable.

So, the use case would be that you build a binary on your machine and distribute it to others that don't have MacPorts? I guess that'd be useful for environments that have a lot of workstations to setup or something like that.

I think the easiest thing to do would be to implement #41783 and make sure the environment variable is set for all phases. I honestly can't tell if that's happening or not by reading the code in portutil.tcl.

Incidentally, I think it's possible that the originator of this bug /had/ upgraded his machine from 10.8 to 10.9, his “clean install” iin comment 4 was only of mercurial, and this problem might appear if macports hadn't been upgraded properly after the OS upgrade.

Yes, I agree.

[ryandesign (Ryan Carsten Schmidt)]

Please stop discussing the usefulness or non-usefulness of the macosx_deployment_target portfile option in this ticket. This ticket is about a specific build failure that one user is experiencing. Sorry, I did not realize when I closed this ticket that the person I was responding to was not the person who opened this ticket. Dear person who opened this ticket: please attach a main.log file showing the complete build log up to the failure.

[petr.fischer@…]

Sorry guys, but in time-press I switched to Homebrew. main.log is gone. Close or ignore this ticket.

[ryandesign (Ryan Carsten Schmidt)]

Ok, in that case we have nothing to go on.