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/


Reply via email to