questions about uclibc 0.9.30 elf type "FILE"

Khem Raj raj.khem at gmail.com
Thu Jan 22 19:01:15 UTC 2009


On Thu, Jan 22, 2009 at 10:39 AM, Kevin Day <thekevinday at gmail.com> wrote:
> On Wed, Jan 21, 2009 at 9:35 PM, Kevin Day <thekevinday at gmail.com> wrote:
>> On Wed, Jan 21, 2009 at 8:43 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>> On Wed, Jan 21, 2009 at 4:02 PM, Kevin Day <thekevinday at gmail.com> wrote:
>>>> During a test compilation of my system under uClibc 0.9.30, xterm
>>>> failed to link because the function getpt was unresolved.
>>>>
>>>> Looking in /lib/libc.so of 0.9.30 with readelf showed that getpt was
>>>> defined as type  "FILE" with a name of "getpt.c" (notice the trailing
>>>> .c)
>>>
>>> thats a different symbol
>
> After doing some extended research, I believe that symbol is STT_FILE?
> The different documentation that I found was quite sparse in their
> explanation of STT_FILE...
> From what little I read, STT_FILE allows for including local symbols
> that are specific to individual (object) files.
>
> So, I am left wondering as to why the getpt.c was still having an
> STT_FILE definition inside of the libc when the getpt() functionality
> was disabled by the .config option.
>
> If getpt() is not going to be used, why have the local references
> still attached?

if you do not enable the function then the function is ifdef'ed out
but the file still compiles even if it is empty or may be there
are other functions provided by this file. Every source file name gets
emitted into symbol table as STT_FILE in ELF and thats what you
see.

If you do not want them then strip them out like
strip -w --strip-symbol=*.c <your binary>

>
>
> --
> Kevin Day
>


More information about the uClibc mailing list