Opened 9 years ago
Last modified 8 years ago
#49421 assigned defect
gmake should use --disable-nls to avoid CoreFoundation linkage via libintl
Reported by: | howarth.at.macports@… | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | Cc: | ||
Port: | gmake |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
In debugging the build failures in the fink project when make 4.1 was used, we have shown that the CoreFoundation framework isn't safe to use with the fork()/exec() needed by make.
http://thread.gmane.org/gmane.os.macosx.fink.devel/23072
The build failures under fink when make 4.1 is used can also be suppressed with --enable-nls if gettext is built with...
gt_cv_func_CFPreferencesCopyAppValue=no \ gt_cv_func_CFLocaleCopyCurrent=no \ gt_cv_func_CFPreferencesCopyAppValue=no \ gt_cv_func_CFLocaleCopyCurrent=no
to avoid linking libintl against the CoreFoundation framework. Since this would reduce the functionality of gettext, building make 4.1 with --disable-nls (which is how the system make is built) is the better approach.
The CoreFoundation linkage, in the indirectly linked libintl, immediately caught my eye because pymol also relies on fork()/exec() and requires the -CoreFoundation variant of tcl in order to avoid crashes. If you examine the sources of CoreFoundation, you will also see that there isn't any EINTR handling for system calls like read(), write() and (f)stat() which can return EINTR. If you look at the sources in gettext-0.19.5.1/gettext-runtime/intl, you will see that code like...
to_read = size; read_ptr = (char *) data; do { long int nb = (long int) read (fd, read_ptr, to_read); if (nb <= 0) { #ifdef EINTR if (nb == -1 && errno == EINTR) continue; #endif goto out; } read_ptr += nb; to_read -= nb; }
is used to insure that if a read() returns EINTR, the call is considered to be interrupted and is retried until it either fails without EINTR or succeeds.
Change History (3)
comment:1 Changed 9 years ago by howarth.at.macports@…
comment:2 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | stuartwesterman@… removed |
---|---|
Description: | modified (diff) |
Owner: | changed from macports-tickets@… to stuartwesterman@… |
comment:3 Changed 8 years ago by mf2k (Frank Schima)
Owner: | stuartwesterman deleted |
---|---|
Status: | new → assigned |
Note that while this bug isn't tickled under port, I have shown that the gmake binary built under MacPorts (when symlinked into /sw/bin to replace the fink copy of make 4.1) exhibits the same parallel build failures when executed through fink under perl.