Max,
I finally have a good handle on the origin of the breakage in 10.11.
Looking through the sources for intl in gettext-0.19.5.1, I only found a
fstat call missing the EINTR handling but adding that didn't fix the
parallel make regressions in the openmpi and gcc5 builds under make 4-1-3.
However I dd notice that gettext builds and links against the
CoreFoundation framework. So I did the test of rebuilding
libgettext8-shlibs and gettext-tools with...
gt_cv_func_CFPreferencesCopyAppValue=no \
gt_cv_func_CFLocaleCopyCurrent=no \
gt_cv_func_CFPreferencesCopyAppValue=no \
gt_cv_func_CFLocaleCopyCurrent=no
passed to ConfigureParams in order to avoid building against the
CoreFoundation framework. The resulting libintl now allows the current
make-4.1-3 (which is built with the NLS support) to parallel build both the
openmpi and gcc5 package.
Since we don't want to remove the CoreFoundation support from
libgettext8-shlibs and gettext-tools, the obvious solution is to use the
proposed make-4.1-4 packaging....
https://sourceforge.net/p/fink/package-submissions/4563/
which passes --disable-nls to ConfigureParams to avoid linking against
libintl entirely.
Jack
ps I'll probably file a radar but I don't have much hope that Apple can be
convinced to code review CFPreferencesCopyAppValue, CFLocaleCopyCurrent,
CFPreferencesCopyAppValue and CFLocaleCopyCurrent with their associated
calls for EINTR handling on system calls.
pps This actually isn't that surprising. On MacPorts, we have to use the
-CoreFoundation variant of their tcl package to allow pymol to run properly
and pymol does a fork()/exec() like make does.
On Fri, Oct 23, 2015 at 4:30 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:
> Since make 4.1 built with --enable-nls only links against
> /sw/lib/libintl.8.dylib, the only likely candidate I see is...
>
> __builtin_expect (fstat (fd, &st) != 0, 0)
>
> in gettext-0.19.5.1/gettext-runtime/intl/loadmsgcat.c. It's not clear how
> we manage to keep the __builtin_expect macro wrapper while also looping on
> fstat with the missing check for EINTR added.
> Jack
> ps In theory, we probably should also check the i/o system calls for
> missing EINTR checks in /sw/lib/libiconv.2.dylib since libintl.8.dylib is
> linked against that.
>
> On Fri, Oct 23, 2015 at 3:22 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> Max,
>> I did an exhaustive check by adding EINTRLOOP macros to every
>> single POSIX system call in the make 4.1 sources which can return EINTR.
>> None of that helped eliminate the build failures here in openmpi and gcc5.
>> I finally stumbled in a workaround that suppresses the failures. Passing
>> --disable-nls to the ConfigureParms in the make 4.1 build produces a binary
>> that doesn't exhibit this bug on 10.11.
>> This work-around actually makes sense to me. If the read/write/stat
>> calls in the make 4.1 sources require addition of an EINTRLOOP macro
>> wrapper, then why shouldn't the same be true of those function calls in the
>> gettext library itself.. Any i/o in that library should be under that same
>> restrictions as those in the make 4.1 sources themselves, no?
>> Jack
>> ps The attached make-4.1-4 applies --disable-nls universally to the build
>> so that binaries built prior to the upgrade to 10.11 will have the same
>> necessary elimination of that feature.
>> ppc The explanation of the failure being due to the NLS support also has
>> the added benefit of explaining why this issue was quasi-latent in prior
>> darwin releases...
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5
>>
>> Looking at the gettext-0.19.5.1 sources, I see that their read calls use
>> a while loop to check for EINTR being returned but this doesn't rule out
>> that some other POSIX call in there is missing the required EINTR checks.
>> For instance in gettext-tools/gnulib-lib/pipe-filter-ii.c,
>>
>> read (fd[0], buf, bufsize > SSIZE_MAX ? SSIZE_MAX :
>> bufsize);
>>
>> looks like it might need a EINTR check. IMHO, gnu-lib might be the best
>> place to start as that code isn't under the direct control of the gettext
>> developers. It also seems to do write() and stat() calls without checking
>> for EINTR in places within the gnu-lib sources.
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
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
