https://sourceware.org/bugzilla/show_bug.cgi?id=28719
--- Comment #7 from Nick Clifton <nickc at redhat dot com> --- (In reply to Achim from comment #6) > So it turns out that removing the section at that commit (as I had done > during bisecting) would actually restore the previous behaviour (the > executable would not run). Applying the same fix on top of both the 2.37 > and 2.38 releases doesn't, however. So it seems that one of the later > commits would be responsible for the actual resolution of the weak symbol. Hmm, I suspect that this is going to be hard to track down. One thing I am not sure about however is the involvement of the cygwin.a library. The trace you reported in comment #4 shows that it is being used to resolve the weak reference to fputs. Presumably this should not be happening, but why not ? Should cygwin.a not be included in the link ? Or should it be included but not used to resolve weak references ? Or ... included, used to resolve non-weak references, but if a member of the archive is used to resolve a non-weak reference then that member can then also be used to resolve weak references. In which case, the problem is why is the t-d000578.o member of cygwin.a being pulled in in the first place ? (I am also wondering if this problem has anything to do with the changes made to the xcoff_link_check_ar_symbols() function in bfd/xcofflink.c). -- You are receiving this mail because: You are on the CC list for the bug.
