On Mon, Sep 21, 2015 at 1:48 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:
>
>
> 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.
>
A bit closer to fink was duplicated with...
cd tests
sudo -u fink-bld make clean
cd ..
/usr/bin/perl -e 'system("sudo", "-u". "fink-bld", "/tmp/fink.U7E7Q")'
and this also refuses to trigger the bug outside of fink itself.
------------------------------------------------------------------------------
_______________________________________________
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
