Fwd: Duplicate strings in the ld-2.17.90 PO file
It turns out that the binutils mailing list is the contact address for this package, as well. So here's another well-travelled email. Begin forwarded message: Hello again :) As I have requested before, please encourage GNU developers to fill in the Report-Msgid-Bugs-To header [1], so we translator do have an accurate contact address for reports like these. I have noticed that more GNU PO files do have this header filled in, so we're heading in the right direction. Slowly. ;) About the ld-2.17.90 PO file: ___ 1. There are some duplicate strings, varying only in whitespace. You may want to reduce these: they can also result in varying translations (I only noticed them because I was reviewing the whole file). (a) #: emultempl/armcoff.em:72 #, c-format msgid " --support-old-code Support interworking with old code\n" #: emultempl/pe.em:325 #, c-format msgid " --support-old-code Support interworking with old code\n" (b) #: emultempl/armcoff.em:73 #, c-format msgid " --thumb-entry= Set the entry point to be Thumb symbol \n" #: emultempl/pe.em:326 #, c-format msgid " --thumb-entry= Set the entry point to be Thumb \n" (c) #: emultempl/armcoff.em:121 #, c-format msgid "Errors encountered processing file %s" #: emultempl/pe.em:1334 #, c-format msgid "Errors encountered processing file %s\n" (There is a line-break difference between these two strings, so I'm unsure if they both have utility, or not. With two sets duplicate strings, it seemed worth mentioning this one as well.) (d) #: ldexp.c:1054 #: ldexp.c:1079 #, c-format msgid "%F%S nonconstant expression for %s\n" #: ldexp.c:1138 #, c-format msgid "%F%S: nonconstant expression for %s\n" (A colon is the only difference, which again might be useful, or not.) 2. #: emultempl/armcoff.em:194 #: emultempl/pe.em:1533 msgid "%P: warning: connot find thumb start symbol %s\n" - connot + cannot 3. #: ldmisc.c:245 #, c-format msgid "built in linker script:%u Should there be a space after the colon? 4. I don't know if you want to abbreviate these as much as possible, or if you would prefer that they were correct English: (a) #: lexsup.c:210 msgid "Specify target for following input files" "Specific the target for the following input files" Other strings where "the following" could be substituted for just "following": #: lexsup.c:329 msgid "" "Set DT_NEEDED tags for DT_NEEDED entries in\n" "\t\t\t\tfollowing dynamic libs" #: lexsup.c:332 msgid "" "Do not set DT_NEEDED tags for DT_NEEDED entries\n" "\t\t\t\tin following dynamic libs" #: lexsup.c:335 msgid "Only set DT_NEEDED for following dynamic libs if used" #: lexsup.c:338 msgid "Always set DT_NEEDED for following dynamic libs" I hope this is useful. from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN [1] As the gettext documentation says: Report-Msgid-Bugs-To This has already been filled in by `xgettext'. The developer thus needs to pass the option --msgid-bugs-address=... to xgettext. With recent gettext infrastructure this is a field in po/Makevars that the developer fills in; the rest is automatic. ___ (in short for programmers: put a C-style comment immediately _before_ the gettext (macro) invocation). ___ [EMAIL PROTECTED] set report address for msgid bugs\n PGP.sig Description: This is a digitally signed message part ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4907] readelf doesn't dump .eh_frame_hdr section
--- Additional Comments From jakub at redhat dot com 2007-08-16 08:46 --- Why should it? It contains only precomputed redundant info which you can find out from readelf -S (i.e. where .eh_frame section is located) and readelf -wf. -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4907 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4928] Linker should check code sequence before TLS optimization
--- Additional Comments From jakub at redhat dot com 2007-08-16 08:47 --- Which compilers violate the TLS ABI? tls.pdf clearly says that the sequences are not optional, if you use the corresponding relocations, you must use them only in the listed sequences. -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4928 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4907] readelf doesn't dump .eh_frame_hdr section
--- Additional Comments From hjl at lucon dot org 2007-08-16 13:00 --- I may want to verify if the content of .eh_frame_hdr is correct by dumping and checking it. It is hard to interpret the output of "readelf -S". -- What|Removed |Added Status|WAITING |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=4907 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4928] Linker should check code sequence before TLS optimization
--- Additional Comments From hjl at lucon dot org 2007-08-16 13:08 --- 1. Those sequences may not be optimal in all cases. If compiler knows those optimizations won't be performed, it can generate better sequence. But sometimes compiler may be wrong and we wind up with code sequences which can't not be optimized. 2. Skip those optimizations will not affect the correctness of the program. But performing those optimizations on different sequence will result in bad program. At least, linker shouldn't knowingly generate bad program. -- What|Removed |Added Status|WAITING |NEW http://sourceware.org/bugzilla/show_bug.cgi?id=4928 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4928] Linker should check code sequence before TLS optimization
--- Additional Comments From drow at false dot org 2007-08-16 13:19 --- Subject: Re: Linker should check code sequence before TLS optimization On Thu, Aug 16, 2007 at 01:08:34PM -, hjl at lucon dot org wrote: > 1. Those sequences may not be optimal in all cases. If compiler knows Then discuss ABI changes, please. ABI documents are not optional to follow! -- http://sourceware.org/bugzilla/show_bug.cgi?id=4928 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4928] Linker should check code sequence before TLS optimization
--- Additional Comments From hjl at lucon dot org 2007-08-16 13:29 --- (In reply to comment #3) > Subject: Re: Linker should check code sequence before TLS > optimization > > On Thu, Aug 16, 2007 at 01:08:34PM -, hjl at lucon dot org wrote: > > 1. Those sequences may not be optimal in all cases. If compiler knows > > Then discuss ABI changes, please. ABI documents are not optional to follow! > In this case, linker is generating the final result. This linker "optimization" I am proposing will generate correct output with better performance and without affecting interoperability, which an ABI is used for. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4928 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
