> On Oct 1, 2015, at 12:24, Alexander Hansen <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 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.
--
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
