[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Arvind Sankar changed: What|Removed |Added CC||niveditas98 at gmail dot com ---

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #10 from Nick Bowler --- (In reply to Martin Liška from comment #9) > > Amusingly, "nm" is also busted on objects using this trick with -flto, > > showing a_ as an undefined symbol which is not the case. But that > >

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #9 from Martin Liška --- > > Amusingly, "nm" is also busted on objects using this trick with -flto, > showing a_ as an undefined symbol which is not the case. But that > shouldn't cause any issue for libtool's uses of nm.

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #8

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #7 from Nick Bowler --- (In reply to Nick Clifton from comment #6) > (In reply to Nick Bowler from comment #5) > > > - The configure test actually links together the results for two > >features (global_symbol_pipe and

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #6 from Nick Clifton --- (In reply to Nick Bowler from comment #5) > - The configure test actually links together the results for two >features (global_symbol_pipe and global_symbol_to_cdecl). The following suggestion is an

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #5 from Nick Bowler --- (In reply to Martin Liška from comment #4) > That's true, but it's only related to .o files (LTO bytecode). If you link > a final executable (or a shared library), you'll get proper type information: > > $

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added CC||bfriesen at simple dot dallas.tx.u

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #4 from Martin Liška --- (In reply to Nick Bowler from comment #2) > Summary of the issue in libtool: > > libtool needs to produce C declarations for arbitrary symbols based on nm > output, in order to implement various features

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Calvin Walton changed: What|Removed |Added CC||calvin.walton at kepstin dot ca ---

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca --- Comment

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment