On Sat, Sep 19, 2015 at 9:13 AM, Max Horn <m...@quendi.de> wrote:
> Hi again,
>
> On 16.09.2015, at 14:42, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> > MacPorts gmake doesn't show the problem on the command line or in their
> builds but I have only been able to test a rather narrow set of MacPorts
> builds against their gmake. However I have been able to reproduce the build
> failures under fink when the call to 'make' is substituted with
> '/opt/local/bin/make' to invoke their copy.
>
> That's interesting, and a bit weird... But at least it suggest that it is
> directly not our "fault" for breaking GNU make, it may just be broken in
> general on Mac OS X 10.11... Not that this insight helps anybody faced with
> the problem :-/.
>
>
>
> > I doubt a unique set of packages exists to protect from this bug with
> the usage of /usr/bin/make. The bug looks to be a race condition in the
> threading support as tweaking the optimization of make build modulates the
> number of packages that fail under fink make. Likewise reducing the number
> of cores in the parallel build can suppress the bug. Also, when I debugged
> this by adding -d, only one of the failing tests, texlive-base, remained
> and even then only randomly. So the real question will be how many users
> machines have the cores/speed to tickle the bug. My past experience with
> Apple and threading bugs is that it is futile to expect them to be fixed in
> a given OS release and usually you have to wait for the next major kernel
> rewrite.
>
> So, what shall we do then?
>
>
> * Just "patch" affected packages to workaround the issue
>
> * Split "make" as Jack proposed (i.e. package "make" only provides a
> "gmake" binary, and "make-default" provides a "make" symlink to it, similar
> to e.g. coreutils-default).
> However, I'd prefer to *only* do that on 10.11, as to minimize the
> impact this has on users. That said, my hope is that whether Apple's and
> our make is used for most users...
>
>
> Cheers,
> Max
Max,
The regression seems impossible to duplicate outside of fink. Using
the libcurl4 build which fails in fink make during the InfoTest run and a
copy of fink modified to emit the contents of %ENV with...
--- PkgVersion.pm.orig 2015-09-21 12:57:25.000000000 -0400
+++ PkgVersion.pm 2015-09-21 13:05:37.000000000 -0400
@@ -5230,6 +5230,11 @@
$nonroot_okay = $nonroot_okay && $build_as_nobody;
{
local %ENV = %{$self->get_env($phase)};
+ my @keys = keys %ENV;
+ my @values = values %ENV;
+ while (@keys) {
+ print pop(@keys), '=', pop(@values), "\n";
+ }
$result = &execute($script, nonroot_okay=>$nonroot_okay);
}
if ($result and !$ignore_result) {
I used the /tmp/fink.U7E7Q InfoTest script left from the failed build with
the addition of...
use lib "/sw/lib/perl5";
and -j8 appended to the make line as well as export lines in the bash
script for all of the environmentals reportedly set during the failing
InfoTest run. Executing...
[Jack-Howarths-Computer:fink.build/libcurl4-7.44.0-1+10.8/curl-7.44.0]
howarth% sudo -u fink-bld /tmp/fink.U7E7Q
repeatedly succeeds whereas the fink -m build constantly fails in the
InfoTest. Weird.
Jack
ps The only thing left to do is try to craft an additional layer of
indirection such that the execution of /tmp/fink.U7E7Q is done from within
perl rather than on the command line.
------------------------------------------------------------------------------
_______________________________________________
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
