On Sat, Sep 19, 2015 at 9:41 AM, 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, > 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, > > > Alternatively, perhaps dpkg is the trigger? Does anyone know if it is possible to trick fink's dpkg to build a package on the command line outside of fink and thus the system perl? That would be an interesting test to use on one of the failing package builds.
------------------------------------------------------------------------------
_______________________________________________ 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
