From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin v. Loewis" To: Al_Niessner@bigfoot.com Cc: gcc-help@gcc.gnu.org Subject: Re: gcc symbol names Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <200002280926.KAA13053@loewis.home.cs.tu-berlin.de> References: <38B8A8F8.C2403E51@bigfoot.com> <200002271918.UAA01018@loewis.home.cs.tu-berlin.de> <38B98706.F7E6C0B@bigfoot.com> <200002272050.VAA17639@loewis.home.cs.tu-berlin.de> <38B9E37F.F303D4DD@bigfoot.com> X-SW-Source: 2000-q1/msg00294.html Message-ID: <20000401000000.azYsbzGLwYG2yelanNoBBarL_CynlMMs88r_S3vUSR0@z> > The second column of nm (first column in the text below) the case of > the letter is different (neither the man nor info tell me what it is > supposed to mean) or just different letters. You didn't really look, did you? In by binutils info page, on (binutils)nm `T' The symbol is in the text (code) section. If lowercase, the symbol is local; if uppercase, the symbol is global (external). So the symbol is global in one case, and local in the other. That should not be a problem, provided the linker magic for global object construction continues to work. Since it should be an ELF target, making the symbols local is the right thing to do. The difference in 'g' vs 'b' is between `G' The symbol is in an initialized data section for small objects. Some object file formats permit more efficient access to small data objects, such as a global int variable as opposed to a large global array. `B' The symbol is in the uninitialized data section (known as BSS). so that should not matter, either. Also asso_values.8464 is a synthetic name indicating generated for a local variable; the numbering may have changed for some reason, but it should not be relevant (unless the function is inline). > Any suggestions on how to resolve these last few issues? Why do you need to resolve them? Anyway, coming back to my earlier point: You really should recompile all those libraries, as nobody will give you a guarantee that they continue to work even if you manage to link them. Martin