https://sourceware.org/bugzilla/show_bug.cgi?id=33577
--- Comment #35 from Michael Matz <matz at suse dot de> --- Well, citing a Sun specification from the 90's is relevant, because Ali used the ARCs to point at the original intent of NDX_LOCAL (and it being more along the line of "unknown version"), and the docu shows that that wasn't explicitely put down externally back then (i.e. added only later there). Now, whatever the original intent may have been (and I of course agree, it absolutely makes sense to use '0' as the nothing-known index for mere references), it wasn't what was written in most places, which only was NDX_LOCAL - local scope [full stop] . There really isn't much wiggle room in interpreting that single line (and to remind, the GNU version stuff was designed in large part by getting inspired by relevant and available Sun docs). Either way, that is what several binary tools implemented over a long time, and we can't now willy-nilly change that without some allowance period for that change. I will note that the original report from Rainer here was about a mere perceived inconsistency in objdump output, not any specific breakage. It seems a disservice to fix that confusion by introducing real breakage with other linkers. So, IMHO: we (GNU ld) should continue to emit NDX_GLOBAL for the undefined symbols, as we had. Other linkers should be changed to not particularly care for either NDX_LOCAL or NDX_GLOBAL for undefined symbols (GNU ld already is fine with NDX_LOCAL on such syms). Then, wait a release, then change GNU ld to emit NDX_LOCAL. -- You are receiving this mail because: You are on the CC list for the bug.
