On Thu, Jan 22, 2009 at 10:39 AM, Kevin Day <[email protected]> wrote:
> On Wed, Jan 21, 2009 at 9:35 PM, Kevin Day <[email protected]> wrote:
>> On Wed, Jan 21, 2009 at 8:43 PM, Khem Raj <[email protected]> wrote:
>>> On Wed, Jan 21, 2009 at 4:02 PM, Kevin Day <[email protected]> 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
>
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to