Since we now know that glibc does not support all the keywords
mentioned in ISO/IEC TR 14652 [1] and in general glibc aims to
be conforming to POSIX first and foremost, I think it's best
just to drop the reference to ISO/IEC TR 14652 from the man page.
1) http://www.open-std.org/jtc1/SC22/WG20/docs/n972-14652ft.pdf
After this I think the locale related man pages are finally as
complete as they need to be.
Cross-checked the current locale.5 page against glibc locales and
fixed the following issues:
- mention define/ifdef/else/endif
- mention reorder-sections-{after,end}
- mention script
- section/section-symbol are not used, only mentioned in the ISO TR
- Fix int_currency_symbol -> int_curr_symbol typo
- few formatting fixes
All the glibc locale/repertoiremap files use the format described
in the patch. The fix is trivial (and adds an example just in
case), I presume these were copypasted from charmaps.5 page, all
the glibc charmaps use slightly different format for keywords
(I'll send a separate patch to address charmaps.5 next).
There was partial duplication, and some extra information
in namespaces(7). Move everything to proc(5).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's the first attempt to (almost) complete the locale.5 manual
page by documenting all (but perhaps one) of the missing
LC_COLLATE keywords.
I think the LC_COLLATE section is still not enough to be used as
the only source when writing collation rules from scratch but
perhaps that's not even needed, it could be also thought that
the section 5 pages merely describe the format used in the files.
Naturally more information could be added later on top of this
patch.
Few notes:
- AFAICS coll_weight_max is not used anywhere in glibc
- I'm not aware of any C library implementation on Linux (for
which this manual page would be relevant) which would
implement the POSIX options not supported by glibc
- the glibc specific script keyword could still be documented
Sources:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.htmlhttp://www.open-std.org/jtc1/SC22/WG20/docs/n972-14652ft.pdf
PS. A couple of unrelated comment clean-ups slipped in as well,
sorry about those.
Document DirectMap4k, DirectMap4M, DirectMap2M, DirectMap1G
See https://bugzilla.kernel.org/show_bug.cgi?id=106281
Reported-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Mike:
gabi says:
https://refspecs.linuxbase.org/elf/gabi4+/ch4.symtab.html
A symbol defined in the current component is protected if it is
visible in other components but not preemptable, meaning that
any reference to such a symbol from within the defining component
must be resolved to the definition in that component, even if
there is a definition in another component that would preempt by
the default rules. A symbol with STB_LOCAL binding may not have
STV_PROTECTED visibility. If a symbol definition with
STV_PROTECTED visibility from a shared object is taken as
resolving a reference from an executable or another shared object,
the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
solaris/oracle says:
https://docs.oracle.com/cd/E26502_01/html/E26507/chapter6-79797.html
A symbol that is defined in the current component is protected
if the symbol is visible in other components, but cannot be
preempted. Any reference to such a symbol from within the defining
component must be resolved to the definition in that component.
This resolution must occur, even if a symbol definition exists in
another component that would interpose by the default rules.
A symbol with STB_LOCAL binding will not have STV_PROTECTED
visibility.
but i think this ibm article is probably the most understandable:
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/
The symbol is visible outside the current executable or shared
object, but it may not be overridden. In other words, if a
protected symbol in a shared library is referenced by an other
code in the shared library, the other code will always reference
the symbol in the shared library, even if the executable defines
a symbol with the same name.
Reported-by: Gabriel Corona <gabriel.corona@enst-bretagne.fr>
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note also the pre-3.1 bug in the display of this info.
Reported-by: Patrick Donnelly <batrick@batbytes.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>