[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-gettext] [bug #38783] Invalid check for __fsetlocking
From: |
Bruno Haible |
Subject: |
[bug-gettext] [bug #38783] Invalid check for __fsetlocking |
Date: |
Mon, 12 Dec 2016 01:20:20 +0000 (UTC) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 |
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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug-gettext] [bug #38783] Invalid check for __fsetlocking,
Bruno Haible <=