> On Oct 14, 2015, at 15:54, Alexander Hansen <alexanderk.han...@gmail.com> > wrote: > > >> On Oct 14, 2015, at 15:27, Jack Howarth <howarth.at.f...@gmail.com >> <mailto:howarth.at.f...@gmail.com>> wrote: >> >> >> >> On Wed, Oct 14, 2015 at 5:24 PM, Alexander Hansen >> <alexanderk.han...@gmail.com <mailto:alexanderk.han...@gmail.com>> wrote: >> >>> On Oct 1, 2015, at 12:24, Alexander Hansen <alexanderk.han...@gmail.com >>> <mailto:alexanderk.han...@gmail.com>> wrote: >>> >>> >>>> On Oct 1, 2015, at 11:41, Alexander Hansen <alexanderk.han...@gmail.com >>>> <mailto:alexanderk.han...@gmail.com>> wrote: >>>> >>>>> >>>>> On Oct 1, 2015, at 11:24, Jack Howarth <howarth.at.f...@gmail.com >>>>> <mailto:howarth.at.f...@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth <howarth.at.f...@gmail.com >>>>> <mailto:howarth.at.f...@gmail.com>> wrote: >>>>> >>>>> >>>>> On Thu, Oct 1, 2015 at 12:33 AM, William G. Scott <wgsc...@ucsc.edu >>>>> <mailto:wgsc...@ucsc.edu>> wrote: >>>>> In the course of building some of my packages, a few dependencies failed >>>>> to compile, requiring minor tweaks: >>>>> >>>>> gtk+2 — I had to change to UseMaxBuildJobs: false >>>>> libvpx14 — I had to change to UseMaxBuildJobs: false >>>>> >>>>> Bill, >>>>> I suspect you have the fink make package installed, no? If so, the >>>>> failures should have been accompanied with an error message of the form... >>>>> >>>>> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8! >>>>> >>>>> This breakage in the parallel make of fink make impacts a slew of fink >>>>> package builds on machines with more than 2 cores (eg the cmake, >>>>> libcurl4, texlive-base, etc builds). >>>>> A better fix would be to revert your package back to UseMaxBuildJobs: >>>>> true but hard code' /usr/bin/make' rather than just 'make'. >>>>> Jack >>>>> ps The issue seems to be limited to running fink make from within perl >>>>> under fink. I've not been able to reproduce the build failures outside of >>>>> fink or with just within perl itself. >>>>> >>>>> Actually, I never saw a problem building gtk+2 on a dual quad-core MacPro >>>>> but this re-enforces my suspicion that the problem with fink make is a >>>>> threading race condition that will selectively trigger depending on the >>>>> number of cores and processor speed of a given machine (meaning that all >>>>> parallel builds under fink make on 10.11 are fragile). Perhaps a better >>>>> fix would be to have fink conditionally use /usr/bin/make rather than >>>>> make for the CompileScript's default_script when executed on 10.11. This >>>>> would at least automatically solve the issue for all packages using >>>>> %{default_script}. >>>>> >>>> >>>> We can default to /usr/bin/make on 10.9-10.11 unconditionally and let >>>> individual packages that need fink’s make override that in their >>>> CompileScripts. That’d be simpler, and more consistent with our general >>>> practices with regard to build tools. >>>> >>>> Then we can add a conditional if Apple decides to stop shipping a >>>> /usr/bin/make with Xcode. >>>> -- >>>> Alexander Hansen, Ph.D. >>>> Fink User Liaison >>> >>> I just created a default-to-usr-bin-make branch off of the fink-0.39.x >>> release tree and an accompanying pull request: >>> >>> https://github.com/fink/fink/pull/125 >>> <https://github.com/fink/fink/pull/125> >>> >>> People who are interested in testing whether defaulting to /usr/bin/make >>> has any unforeseen consequences can do so by checking out that branch and >>> using inject.pl <http://inject.pl/> to install it. >>> >>> Because this is branched from the release branch, a selfupdate will still >>> bring you a new release fink-0.39.x when one comes out. >>> >>> -- >>> Alexander Hansen, Ph.D. >>> Fink User Liaison >>> >> >> The pull request (which also changes some other system tool invocations >> explicitly to use built-in versions) has been merged into branch_0_39 as >> well as master. >> >> Note that this only overrides the %{default_script} behavior—packages with >> custom CompileScripts that don’t use %{default_script} will need to to >> enforce /usr/bin/make manually if they need to do that. >> >> You probably also want to switch the fink make package over to building >> gmake and use a symlink to make in a make-default split-off. The make 4.1 >> release is badly destabilized on 10.11 under fink and I suspect that a large >> number of packages will eventually fail for someone or another depending on >> their exact hardware configuration (since this seems to be a race condition). >> Jack >> ps I would be interested to find out if anyone manages to trigger these >> failures in any package build outside of fink itself. The problem seems to >> be entirely specific to running fink make under the fink/perl combination. >> MacPorts seems entirely immune but they don't build under perl. >> >> >> -- >> Alexander Hansen, Ph.D. >> Fink User Liaison >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Fink-devel mailing list >> Fink-devel@lists.sourceforge.net <mailto:Fink-devel@lists.sourceforge.net> >> List archive: >> http://news.gmane.org/gmane.os.apple.fink.devel >> <http://news.gmane.org/gmane.os.apple.fink.devel> >> Subscription management: >> https://lists.sourceforge.net/lists/listinfo/fink-devel >> <https://lists.sourceforge.net/lists/listinfo/fink-devel> > I can’t think of a single good reason to have a make-default, to be honest, > apart from allowing end-users not to have to remember a new executable name > or change the PATH—my personal choice would be to install Fink’s make in a > private directory so that it’s completely out of the default lookups unless > explicitly called for. > -- > Alexander Hansen, Ph.D. > Fink User Liaison >
Well, that and consistency with past practices. I don’t like coreutils-default, though. It was set up before we standardized how we did private directories. I’d have rather had coreutils bury its utils in a private directory, too.
------------------------------------------------------------------------------
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel