> On Oct 14, 2015, at 15:27, Jack Howarth <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
------------------------------------------------------------------------------
_______________________________________________ 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
