[Bug ld/4515] bad definition of start address in ldscripts for OMAGIC
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-09 11:37 --- http://sourceware.org/ml/binutils-cvs/2007-08/msg00055.html applied to 2.18 branch too. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=4515 --- 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
Errors in the opcodes-2.17.90 PO file
Hello :) I have been trying to find a contact address for opcodes, since the Report-Msgid-Bugs-To field is not filled in in the opcodes translation file. Please fill in [1] this header for all packages you want translated. I hope this is the right address. The bug report (much-travelled) is below. 1. Three strings where a placeholder is not delimited by a space: (a) #: ia64-gen.c:1553 #, c-format msgid "Warning: rsrc %s (%s) has no chks%s\n" (b) #: mips-dis.c:1211 #, c-format msgid "# internal error, undefined modifier(%c)" (c) #: mt-asm.c:157 #, c-format msgid "%operator operand is not a symbol" The third example is a fatal error when checking translations, as gettext will not accept any translation for this strings which does not include "%o", which it thinks is the variable in this case. Please fix this string at least: I have had to fudge my translation, to be able to submit it, by adding an "o" at the beginning. This will quite likely confuse users. (Unless the whole word is the variable, which is far from obvious.) 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 ld/4909] New: request for more helpful "can't allocate in segment" error message
Recently, a sanity-check was added to ld to ensure that the link fails if a section didn't make it into the output file. That seems reasonable enough, but unfortunately, the error message produced does not help at all in tracking down the error. For example, on the Linux kernel, we had to deal with an error message of the form: ld: .tmp_vmlinux1: section `.text' can't be allocated in segment 0 ld: final link failed: Bad value This was due to the fact that a "notes" section was added the to kernel which didn't get linked into the kernel. Fixing the problem was easy, but tracking down the source of the problem was very time-consuming. It would be very helpful if the error message could be improved, so as to give a hint as to where the problem is coming from. -- Summary: request for more helpful "can't allocate in segment" error message Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: enhancement Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: dmosberger at gmail dot com CC: bug-binutils at gnu dot org,hjl at lucon dot org GCC build triplet: any GCC host triplet: any GCC target triplet: any http://sourceware.org/bugzilla/show_bug.cgi?id=4909 --- 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/4875] sha1.h:25:20: error: stdint.h: No such file or directory
--- Additional Comments From hjl at lucon dot org 2007-08-09 18:31 --- A patch is posted at http://sourceware.org/ml/binutils/2007-08/msg00133.html -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4875 --- 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/4909] request for more helpful "can't allocate in segment" error message
--- Additional Comments From hjl at lucon dot org 2007-08-09 19:12 --- A patch is posted at http://sourceware.org/ml/binutils/2007-08/msg00134.html -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4909 --- 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/4909] request for more helpful "can't allocate in segment" error message
--- Additional Comments From dmosberger at gmail dot com 2007-08-09 19:26 --- Subject: Re: request for more helpful "can't allocate in segment" error message Not easy to decode, but yes, that's definitely better! Thanks, --david On 9 Aug 2007 19:12:01 -, hjl at lucon dot org <[EMAIL PROTECTED]> wrote: > > --- Additional Comments From hjl at lucon dot org 2007-08-09 19:12 > --- > A patch is posted at > > http://sourceware.org/ml/binutils/2007-08/msg00134.html > > -- >What|Removed |Added > > Status|NEW |WAITING > > > http://sourceware.org/bugzilla/show_bug.cgi?id=4909 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://sourceware.org/bugzilla/show_bug.cgi?id=4909 --- 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/4875] sha1.h:25:20: error: stdint.h: No such file or directory
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 20:07 --- Subject: Re: sha1.h:25:20: error: stdint.h: No such file or directory > A patch is posted at > > http://sourceware.org/ml/binutils/2007-08/msg00133.html I have tried the second hunk and didn't encounter any problems. Should there be Makefile dependencies added for ld/elf-hints-local.h and ld/sha1.h? Dave -- http://sourceware.org/bugzilla/show_bug.cgi?id=4875 --- 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/4538] don't skip initializers with visible external side effects in static archives
--- Additional Comments From cnmnzusoib at mailinator dot com 2007-08-09
22:01 ---
> That is exactly the behaviour you get with --whole-archive.
Except that --whole-archive brings in *everything*. Is there even a point to
using the static archive at
that point vs. doing an intermediate link to combine into a .o? I'm actually
kind of curious where
whole-archive came from, as it seems like a quick hack to address this very
problem...
What I'm driving at here is to find a way to get the benefit of faster links
via static archive (by leaving
unnecessary stuff out), without skipping initializers with side effects in
translation units which *are*
being used... (thus making those initializers implicitly referenced)
Ideally, only those with external side effects are needed, but I don't think
that level of information is
available to the linker...?
Assuming it isn't, you wind up importing anything with any kind of
initialization section. Still better
than choosing between non-functional code or importing everything. And it
looks like it'll be pretty
effective, and not bother system libraries. Of the 94 .a files under /usr/lib
on a fairly basic Ubuntu box,
comprising 5581 object files, only 19 (a third of a percent!) had .ctor
sections. So even if it's not
optimal, its much better than what we have now.
I'm still kind of hoping there's a more selective way to detect which units
have a side effect in an
already-used unit. If this is something to take up with the compiler venders
(i.e. emit a new section
with the needed information) then so be it, at least then you can leave the
ball in their court.
Also, there's also a side issue of awareness/documentation -- having a flag
whose purpose is to make
sure all the init sections are run raises awareness that some initialization
routines might *not* be run if
you don't use it. Seeing as how I found quite a few threads where people have
run into this problem,
e.g.:
http://gcc.gnu.org/ml/gcc-bugs/2004-06/msg02196.html
http://cygwin.com/ml/cygwin/2007-02/msg00584.html
http://lists.apple.com/archives/xcode-users/2005/Aug/msg00786.html ("I don't
think ld is smart
enough")
http://www.physicsforums.com/archive/index.php/t-106619.html ("This doesn't
work" and the thread
never does seem to figure out what's going on)
http://ciaranm.org/show_post/13 ("evil and broken ", references --as-needed and
DSO, but same
issue)
http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-August/000207.html
("strangeness with
respect to archives and .init processing")
...even just documentation would help avoid wasting people's time. You should
understand that when
"the rest of us" write a static initializer, especially something explicit like
__attribute__((constructor)),
we do actually expect it to run, regardless of whether it's linked via an
archive or not. People don't
expect using an archive vs. other formats to change their results. I don't
think they *should* expect
that, not for something as basic and explicitly covered by the standards as
"will the initializer be run?".
It's clear in the above threads that even of the people who understand the
problem, it's *not what even
they ideally want it to do*.
> But note that the very popular operating systems Windows
> and Mac OS X are not ELF based.
True, OS X calls them __StaticInit and __constructor/__destructor sections and
uses Mach-O, but either
binutils already has code for parsing that or else it doesn't matter anyway...
I don't know about
Windows though, but it's entirely possible different platforms might need
different solutions. OS X's ld
has -all_load instead of --whole-archive, for instance. (sigh)
-ethan
PS I'm switching the severity and summary back to a 'bug' since I still
consider this a fixing a design
flaw more than "enhancement". Shouldn't matter to you since it's still closed
anyway...
--
What|Removed |Added
Severity|enhancement |normal
Summary|add --all-init flag to force|don't skip initializers with
|all static initializers to |visible external side
|be loaded |effects in static archives
http://sourceware.org/bugzilla/show_bug.cgi?id=4538
--- 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/4909] request for more helpful "can't allocate in segment" error message
--- Additional Comments From hjl at lucon dot org 2007-08-09 23:15 --- Fixed by http://sourceware.org/ml/binutils/2007-08/msg00142.html -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=4909 --- 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
