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,
I've been exploring this issue on MacPorts under 10.11 with the
change...
--- /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl.orig 2015-09-18
16:23:32.000000000 -0400
+++ /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl 2015-09-18
18:52:23.000000000 -0400
@@ -56,7 +56,7 @@
variable unzip_path "/usr/bin/unzip"
variable zip_path "/usr/bin/zip"
variable lsbom_path "/usr/bin/lsbom"
- variable make_path "/usr/bin/make"
+ variable make_path "/opt/local/bin/gmake"
variable gnumake_path "/usr/bin/gnumake"
variable bsdmake_path ""
variable mkbom_path "/usr/bin/mkbom"
and...
sandbox_enable no
in /opt/local/etc/macports/macports.conf to disable their default use of
Apple's sandbox during port builds. Building through a large number of
packages (including many that trigger the bug on fink), I have been unable
to trigger the bug (despite the fact the the gmake built by MacPorts can
trigger the bug in fink builds).
I suspect we are looking at some issue specific to building as an
exec() under perl. Unfortunately, so far I have been unable to replicate
the failures when building manually on the command line from inside of the
system perl. The most sensible approach is to continue down that path and
try to enhance the command line testing from within perl until we fully
duplicate the steps being used by fink. Only thing can we file a sensible
radar bug report.
Jack
ps I have also been able to reproduce some of these failures under
fink with MaxBuildJobs: 4,
------------------------------------------------------------------------------
_______________________________________________
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
