GNU gettext - Bugs: bug #38783, Invalid check for __fsetlocking
You are not allowed to post comments on this tracker with your current authentication level.
bug #38783: Invalid check for __fsetlocking
Submitter: | LCID Fire <lcid_fire> | ||
Submitted: | Sat 20 Apr 2013 10:22:05 AM UTC | ||
Category: | Build | Severity: | 3 - Normal |
Item Group: | None | Status: | Not a Bug |
Privacy: | Public | Assigned to: | ueno |
Open/Closed: | Closed |
Jump to the original submission
Mon 12 Dec 2016 01:20:19 AM UTC, comment #7: |
Bruno Haible <haible> |
Mon 22 Apr 2013 05:26:38 AM UTC, comment #6: Anyway, such a decl check in intl.m4 is not for a usual case. There is a comment before gt_CHECK_DECL([feof_unlocked], ...):
|
Daiki Ueno <ueno> |
Sat 20 Apr 2013 07:34:14 PM UTC, comment #5: Well, then how come gettext compiles and runs without any problems on FreeBSD or Mac OS X, where stdio_ext.h does not exist? I'm asking for the actual error, not your understanding. What did you try and what did you get precisely? |
Daiki Ueno <ueno> |
Sat 20 Apr 2013 02:17:23 PM UTC, comment #4: I now applied the commit to both master (https://github.com/abergmeier/emscripten-gettext/commit/a6bac8f7b5ef21dd999198dad6ad8f1e8498cef6) and 0.18.2 branch (https://github.com/abergmeier/emscripten-gettext/commit/f8dba31c634cbef083a70024f42b47554107bad8) on git://git.savannah.gnu.org/gettext.git without any conflict.
|
LCID Fire <lcid_fire> |
Sat 20 Apr 2013 12:41:43 PM UTC, comment #3: Of course I looked at the patch before posting the reply and noticed that the change against intl.m4 does not apply to the current git master. Are you talking about the change in localealias.c?
|
Daiki Ueno <ueno> |
Sat 20 Apr 2013 11:34:37 AM UTC, comment #2: Did you even bother to look at the patch?
|
LCID Fire <lcid_fire> |
Sat 20 Apr 2013 10:51:12 AM UTC, comment #1: It already has the check since 0.16 (the latest release is 0.18.2.1):
|
Daiki Ueno <ueno> |
Sat 20 Apr 2013 10:22:05 AM UTC, original submission:
Since `__fsetlocking` is not defined in a standard header, it has to be checked with it's explicit header ('stdio_ext.h'), or it will fail on some platforms.
|
LCID Fire <lcid_fire> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2016-12-12 | haible | Status | Works For Me | Not a Bug | |
2016-11-27 | haible | Category | None | Build | |
Assigned to | None | ueno | |||
2013-04-20 | ueno | Status | None | Works For Me | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
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.
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.