[Bug ld/996] Linking requires one open file per object file
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:02 --- Oh, and, meanwhile, I'll be trying to reproduce this myself. Thanks! -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=996 --- 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/996] Linking requires one open file per object file
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:01 --- I'm not sure why you're seeing, but it is indeed very plausible that it's my fault. BFD has an open-file cache, and should close files and reopen them as necessary. Do you have any idea what's different after my change? Also, are you able to try restoring the previous implementation of bfd_openr (leaving the changes to bfd_fdopenr) and see if that helps? If so, that suggests that something in the shared code is confused. Thanks! -- What|Removed |Added CC| |mark at codesourcery dot com AssignedTo|unassigned at sources dot |mark at codesourcery dot com |redhat dot com | Status|NEW |ASSIGNED http://sources.redhat.com/bugzilla/show_bug.cgi?id=996 --- 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/996] Linking requires one open file per object file
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:38
---
Subject: Re: Linking requires one open file per object file
mark at codesourcery dot com wrote:
> --- Additional Comments From mark at codesourcery dot com 2005-06-08
> 22:01 ---
> I'm not sure why you're seeing, but it is indeed very plausible that it's my
> fault.
The following patch should fix the problem.
Would you please confirm that it works for you?
Index: opncls.c
===
RCS file: /cvs/src/src/bfd/opncls.c,v
retrieving revision 1.37
diff -c -5 -p -r1.37 opncls.c
*** opncls.c8 Jun 2005 03:51:32 - 1.37
--- opncls.c8 Jun 2005 22:35:41 -
*** DESCRIPTION
*** 222,232
*/
bfd *
bfd_openr (const char *filename, const char *target)
{
! return bfd_fopen (filename, target, FOPEN_RB, -1);
}
/* Don't try to `optimize' this function:
o - We lock using stack space so that interrupting the locking
--- 222,236
*/
bfd *
bfd_openr (const char *filename, const char *target)
{
! bfd *nbfd;
! nbfd = bfd_fopen (filename, target, FOPEN_RB, -1);
! if (nbfd)
! bfd_set_cacheable (nbfd, TRUE);
! return nbfd;
}
/* Don't try to `optimize' this function:
o - We lock using stack space so that interrupting the locking
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=996
--- 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/996] Linking requires one open file per object file
--- Additional Comments From mark at codesourcery dot com 2005-06-09 07:49 --- Fixed with: http://sourceware.org/ml/binutils/2005-06/msg00208.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=996 --- 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/12001] New: Linker includes archive members when symbols therein have already been defined
In this scenario:
f.c
===
void f() {}
main.c
==
int main () { f(); }
$ gcc -c f.c
$ ar cr libf.a f.o
$ gcc main.c -Wl,--defsym=f=4 -L. -lf
the linker pulls in f.o from libf.a, even though f has been explicitly defined
on the command line.
As described here:
http://sourceware.org/ml/binutils/2010-09/msg00110.html
the consensus is that this is a defect in GNU LD and in Gold.
--
Summary: Linker includes archive members when symbols therein
have already been defined
Product: binutils
Version: 2.21 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: mark at codesourcery dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=12001
--- 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/12001] Linker includes archive members when symbols therein have already been defined
http://sourceware.org/bugzilla/show_bug.cgi?id=12001 --- Comment #3 from Mark Mitchell 2010-10-28 15:27:07 UTC --- On 10/28/2010 8:48 AM, nickc at redhat dot com wrote: > In the course of checking the patch I found one linker testcase that broke: > default-script2. I agree. I'm disturbed that there's any evidence that people were relying on the old behavior, but it just seems wrong: This: > _START = DEFINED(_START) ? _START : 0x900; in combination with --defsym _START=... should result in a defined _START. IMO, the most logical interpretation of --defsym is that the linker operate "as if" such definitions occurred at the top of the linker script, in the order they appeared on the command line, so that the script is actually: _START = 0x8000; _START = DEFINED(_START) ? _START : 0x900; And, in that case, of course, _START is defined. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12001] Linker includes archive members when symbols therein have already been defined
http://sourceware.org/bugzilla/show_bug.cgi?id=12001 --- Comment #8 from Mark Mitchell 2010-11-03 17:47:36 UTC --- Nick -- Thanks for fixing this! -- Mark -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12181] local COMDAT group names break linking libstdc++.so with Sun ld
http://sourceware.org/bugzilla/show_bug.cgi?id=12181 --- Comment #3 from Mark Mitchell 2010-11-11 02:02:31 UTC --- For what it's worth, and without knowledge of the Solaris linker, I agree that the code in the Solaris linker seems to be unecessary. I don't see anything wrong with the symbols as they currently stand. It seems slightly undesirable to me to make them global hidden simply because that does mean that the linker will "see" them outside of the object file where they are defined, and that just seems messy. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
