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
