Update of bug #38783 (project gettext):
Status: Works For Me => Not a Bug
_______________________________________________________
Follow-up Comment #7:
The patch you are referring to
(https://github.com/abergmeier/emscripten-gettext/commit/a6bac8f7b5ef21dd999198dad6ad8f1e8498cef6)
has an effect only on platforms on which the questions "does the __fsetlocking
function exist in libc" and "is the __fsetlocking function or macro declared
in <stdio_ext.h>" have a different answer.
The major platforms which have __fsetlocking are glibc and Solaris (7 or
newer), and they declare it as a function (not macro) in <stdio_ext.h>. On
these platforms, the two questions have the same answer, therefore your patch
is a no-op.
On musl 0.9.1 and Haiku, __fsetlocking is declared in <stdio_ext.h>. I don't
have data about whether the function is installed in libc on these platforms.
If not, your patch introduces a regression.
> The problem is that when you use a non gnu libc (for cross compiling),
stdio_ext.h is not present and ____fsetlocking checking did not produce an
error.
It sounds like your cross-compiling setup uses custom include files in
combination with the preinstalled GNU libc in /usr/lib. If so, that would be
an invalid cross-compiling setup.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?38783>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
