> 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

Reply via email to