[Bug ld/10749] Linker failed to build working ia64 kernel
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-12 13:21 --- Unfortunately the patch isn't correct. We might map a unique section to an output section that later has some other section or data mapped. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10749 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
-- What|Removed |Added CC||fche at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From fche at redhat dot com 2009-10-12 16:10 --- IMO, ld's automagic searching is a good thing. Asking a program to enumerate all the indirect dependencies of shared libraries is a burden that they may not be equipped to carry. How do you envision this be automatable? readelf to get DT_NEEDED notes, and form that synthesize -lMMM calls? It is as if header files didn't #include their own dependencies, forcing main.c to do include a topological sorted list of all headers. It's possible but unfair. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From ian at airs dot com 2009-10-12 20:02 --- To be clear, gold does not require that you enumerate all indirect dependencies of shared libraries. gold will not complain if a shared library refers to a function defined in some dependency of that shared library. What gold requires is that you enumerate all direct dependencies of the program itself. If your program calls foo(), then you must explicitly link against some library which defines foo(). The GNU linker permits foo() to be defined indirectly, by a dependency of some shared library which you do explicitly link against. gold does not search those indirect dependencies for symbol definitions. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From ian at airs dot com 2009-10-12 20:15 --- Carrying on, it's true that gold's behaviour does impose a burden when using shared libraries which come in bundles. If a package provides a shared library which includes other shared libraries, and the interface of the package is intended to be the union of all symbols defined in all those shared libraries, then gold's behaviour is suboptimal. So, I guess the question is: how common is that? -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From apratt at us dot ibm dot com 2009-10-12 22:25 --- Pretty common, based on the link in comment #7. The vast majority of those failures are due to unresolved symbols, and it's possible many (most? virtually all?) of them are due to programs expecting the old behavior: symbol resolution via indirect shared-library dependencies. There appears to have been a specific design decision NOT to support indirect symbol resolution in gold. While this can seem "more correct" from one perspective, I think gold could end up like a new compiler that is so strictly standards-compliant it doesn't accept real-world, existing source code. Since the linker is a system-wide choice, a user or developer will be reluctant to install gold if there's a good chance downloaded source projects won't work with it. You could be creating the best linker nobody uses. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From ian at airs dot com 2009-10-12 22:35 --- Comment #7 does not necessarily indicate that there are a lot of packages which provide a union-of-defined-symbols interface. What is indicates is that a lot of people think that linking against the KDE or GNOME libraries also links against the X11 libraries. I didn't make this decision on the basis of an abstract standard of correctness. In areas like linker scripts I've adopted the GNU linker behaviour even when it seems abtractly wrong. I made this decision because the code in the GNU linker which does this is ugly and fragile. It was developed over many years in response to changes in the dynamic linker. In order to work correctly in all cases it must precisely duplicate the dynamic linker, but the dynamic linker changes over time. In all cases that I am currently aware of, the fix to use gold is to add a -l option or two. I think most package maintainers will be willing to do that once they are aware of the issue. Obviously I could be wrong, either about the cause of the problem or the willingness of package maintainers to change. However, I would like to act on the basis of real data rather than speculation. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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/10735] binutils/strings.c fails to compile on OS 10.6.1 / XCode 3.2
-- What|Removed |Added Severity|critical|normal http://sourceware.org/bugzilla/show_bug.cgi?id=10735 --- 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 gas/10740] amd64+i386 as: i8086 Intel syntax far jumps broken (both variants of them)
--- Additional Comments From hjl dot tools at gmail dot com 2009-10-12 23:18 --- Created an attachment (id=4275) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4275&action=view) A patch -- http://sourceware.org/bugzilla/show_bug.cgi?id=10740 --- 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/10654] addr2line gives wrong line number for inlined code
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-12 23:25 --- Fixed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=10654 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From fche at redhat dot com 2009-10-12 23:53
---
I'm confused about whether gold's lack of DT_NEEDED resolution is
intended to affect only pure-indirect or merely mixed-direct-indirect
dependencies. Specifically:
liba { int a() { return b(); } }
libb { int b() { return 0; } }
main() { a() } -la # libb a pure indirect dependency
- versus -
main() { b() } -la # libb a direct dependency
If the latter, I'm more sympathetic to the desire to have a program state
its own direct depencencies.
If the former, I'm more sympathetic to a program not having to know all the
indirect dependencies of all of its shared libraries.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10238
--- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From apratt at us dot ibm dot com 2009-10-13 00:27 --- It's the second one, with a variation. I wouldn't expect your second example to link successfully as written. If you change it so main() calls both a() and b(), it will link with today's GNU linker. That's because when liba comes in (thanks to the call to a), the symbols from its DT_NEEDED libraries are also visible for resolving symbols used in main(), like b. Not so with gold. On the one hand you can say that a link line "should" express the direct, first-order dependencies of the program being linked. But with today's GNU linker, a project's link line does not have to do so. That's what's at issue. Gold risks suffering upon release with this kind of review: "It's great but there are a bunch of existing projects for which it doesn't work, so if you make it your system linker you risk having to tinker with projects you download and build." Over time, I'm sure projects would adapt - at least, those which are being maintained. But user resistance at first release could be a problem for widespread adoption. Of course, whether that's a problem really depends on your goals. I'm going to stop advocating either way because I don't really have a dog in this hunt. For our part, I'm sure we can make PurifyPlus work. I realize the current GNU linker behavior is ill-specified and variable, and it's probably hard to intentionally match any of the organically-evolved implementations. But I would worry about having built-in barriers to adoption out of the gate. I hope Ian can "collect real data rather than speculation" before the initial (wide) release, and version 1.0 gets the kind of reception he and the other project members desire. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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 gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From ian at airs dot com 2009-10-13 00:54 --- As far as I am concerned, gold has been released. The question now is what changes distros will want to see before picking it up as the default linker for those targets which it supports. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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
