On Aug 5, 10:43 am, "S James S Stapleton"
wrote:
> I wanted to examine symbols exported in libraries, I found the tools nm and
> objdump. They are quite useful, and seem to do what I want. However they
> don't work on all libraries. I use them on various libraries in
> /usr/local/lib and /usr/lib, and I get interesting and expected results.
> However, using them on, for example, /lib/libc.so.7
> $ nm /lib/libc.so.7
> nm: /lib/libc.so.7: no symbols
>
> which strikes me as odd.

This is GNU nm? Use 'nm -D /lib/libc.so.7'. There is a distinction
between static and dynamic symbols; shared libraries usually have the
latter.

"S James S Stapleton" writes:

> I wanted to examine symbols exported in libraries, I found the tools nm and
> objdump. They are quite useful, and seem to do what I want. However they
> don't work on all libraries.

Yes, they do; but you have to use correct flags and understand what
you are looking at.

> I use them on various libraries in
> /usr/local/lib and /usr/lib, and I get interesting and expected results.
> However, using them on, for example, /lib/libc.so.7
> $ nm /lib/libc.so.7
> nm: /lib/libc.so.7: no symbols
>
> which strikes me as odd.

That's only because you don't understand the details.

> Is this to be expected? Why?

ELF files may have 0, 1 or 2 separate symbol tables.

The "normal" symbol table may be examined with 'nm foo.o' and
'objdump --syms foo.o', and is used only during "static" linking.

The dynamic symbol table is usually only present in shared libraries
and dynamically-linked executables, may be examined by 'nm -D foo.so'
and 'objdump --dynamic-syms foo.so', and is used by the runtime
loader to bind symbols from an ELF image which references them to
an ELF image which defines them; and also by "static" linker (when
building dynamically-linked executables and shared libraries)
to determine that a referenced symbol will be provided by some
library at runtime, and to suppress "undefined symbol" errors that
would have otherwise resulted.

It is somewhat common to strip the "normal" symbol table from shared
libraries to save space. It is not used after the library is linked.

Note that there are also "hidden" symbols, which are exported by
a shared library and available at runtime, but aren't available to
the "static" linker.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

wrote in message
news:700a5a1c-f98b-479a-8fd9-2b948672cc50@p10g2000prf.googlegroups.com...
> On Aug 5, 10:43 am, "S James S Stapleton"
> wrote:
>> I wanted to examine symbols exported in libraries, I found the tools nm
>> and
>> objdump. They are quite useful, and seem to do what I want. However they
>> don't work on all libraries. I use them on various libraries in
>> /usr/local/lib and /usr/lib, and I get interesting and expected results.
>> However, using them on, for example, /lib/libc.so.7
>> $ nm /lib/libc.so.7
>> nm: /lib/libc.so.7: no symbols
>>
>> which strikes me as odd.
>
> This is GNU nm? Use 'nm -D /lib/libc.so.7'. There is a distinction
> between static and dynamic symbols; shared libraries usually have the
> latter.

Just what I needed. Thanks.

Now, this next one, any idea what it would fit best as, a C question, a Unix
programming question or a GCC question:

I have a variable I want accessible from the dynamic library.
$ nm -D /lib/libc.so.7 | grep ' D '

Amongst other things, I got 'tzname'. To see how they did it (my variables
don't show up in what I'm compiling), I look at:
$ cat /usr/src/lib/libc/stdtime/strftime.c | grep tzname
extern char * tzname[];
pt = _add(tzname[t->tm_isdst != 0],

I was declaring my variables extern in the header, not the C file. I added
extern to my C file for the variables, but now I get an error:
newdel.cpp:5: warning: 'CHAR_TYPE_' initialized and declared 'extern'
newdel.cpp:6: warning: 'CHAR_PTR_TYPE_' initialized and declared 'extern'

The relevant lines of code:
extern type_id CHAR_TYPE_ = -1;
extern type_id CHAR_PTR_TYPE_ = -1;


My library now exports these symobls dynamically.




So, should I be worried about the warnings? The source for my system's libc
does apparantly the same thing. I haven't actually sat and watched the
compiler output, admittedly, so I don't know if it spits the same warnings
for variables in it's libc compile. The os/system compile uses the same
version of GCC.

Thanks,
-Jim Stapleton

On Aug 6, 6:47 am, "S James S Stapleton" wrote:

> I was declaring my variables extern in the header, not the C file. I added
> extern to my C file for the variables, but now I get an error:
> newdel.cpp:5: warning: 'CHAR_TYPE_' initialized and declared 'extern'
> newdel.cpp:6: warning: 'CHAR_PTR_TYPE_' initialized and declared 'extern'
>
> The relevant lines of code:
> extern type_id CHAR_TYPE_ = -1;
> extern type_id CHAR_PTR_TYPE_ = -1;
>
> My library now exports these symobls dynamically.

See section 1.7 of the comp.lang.c FAQ, http://c-faq.com/decl/decldef.html
.. Basically, your header file should contain

extern type_id CHAR_TYPE_;

and exactly one of your source files should contain

type_id CHAR_TYPE_ = -1;

outside of any function.

wrote in message
news:02b0881e-fe86-4293-bdfc-0c2b1b994ffb@r15g2000prd.googlegroups.com...
> On Aug 6, 6:47 am, "S James S Stapleton" wrote:
>
>> I was declaring my variables extern in the header, not the C file. I
>> added
>> extern to my C file for the variables, but now I get an error:
>> newdel.cpp:5: warning: 'CHAR_TYPE_' initialized and declared 'extern'
>> newdel.cpp:6: warning: 'CHAR_PTR_TYPE_' initialized and declared 'extern'
>>
>> The relevant lines of code:
>> extern type_id CHAR_TYPE_ = -1;
>> extern type_id CHAR_PTR_TYPE_ = -1;
>>
>> My library now exports these symobls dynamically.
>
> See section 1.7 of the comp.lang.c FAQ, http://c-faq.com/decl/decldef.html
> . Basically, your header file should contain
>
> extern type_id CHAR_TYPE_;
>
> and exactly one of your source files should contain
>
> type_id CHAR_TYPE_ = -1;
>
> outside of any function.
>
>

Thanks, that's what I thought, but the symbols for my constants didn't show
up in the 'nm -D' call on my object (the functions showed up fine), unless I
put the 'extern' in the C file. As I said, an extern was also in a .c source
file for the system's libc (which came unmodified from the csup of the
source tree). So, for some reason, I have to violate that practice to get
things to work (and that practice is violated in the OS source as well).

Very strange. I'd place the blame solely on me if it were just my source
acting odd. But the oddities in the system source are really making me
wonder.

On Aug 6, 10:59 am, "S James S Stapleton"
wrote:
> wrote in message
>
> news:02b0881e-fe86-4293-bdfc-0c2b1b994ffb@r15g2000prd.googlegroups.com...
> > On Aug 6, 6:47 am, "S James S Stapleton" wrote:
>
> >> I was declaring my variables extern in the header, not the C file. I
> >> added
> >> extern to my C file for the variables, but now I get an error:
> >> newdel.cpp:5: warning: 'CHAR_TYPE_' initialized and declared 'extern'
> >> newdel.cpp:6: warning: 'CHAR_PTR_TYPE_' initialized and declared 'extern'
>
> >> The relevant lines of code:
> >> extern type_id CHAR_TYPE_ = -1;
> >> extern type_id CHAR_PTR_TYPE_ = -1;
>
> >> My library now exports these symobls dynamically.
>
> > See section 1.7 of the comp.lang.c FAQ,http://c-faq.com/decl/decldef.html
> > . Basically, your header file should contain
>
> > extern type_id CHAR_TYPE_;
>
> > and exactly one of your source files should contain
>
> > type_id CHAR_TYPE_ = -1;
>
> > outside of any function.
>
> Thanks, that's what I thought, but the symbols for my constants didn't show
> up in the 'nm -D' call on my object (the functions showed up fine), unless I
> put the 'extern' in the C file. As I said, an extern was also in a .c source
> file for the system's libc (which came unmodified from the csup of the
> source tree). So, for some reason, I have to violate that practice to get
> things to work (and that practice is violated in the OS source as well).

Then something else is wrong. I tried making a shared library the way
I said and it works fine, and the variable does show up in 'nm -D'.
Can you post your code, or reduce it to an example that shows the
problem?

(You *did* recompile and relink everything, right?)

> Very strange. I'd place the blame solely on me if it were just my source
> acting odd. But the oddities in the system source are really making me
> wonder.

There is a crucial difference: in the system source example you cite,
the variable tzname is not explicitly initialized. If you do not want
to initialize your variable, it is okay to put 'extern type_id
CHAR_TYPE_;' in your header, and never have an explicit definition
'type_id CHAR_TYPE_ = 0;' . The linker will automatically initialize
it to zero (or for an array, all zeros). But since it appears you
want the value -1 instead, you can't do this in your program; you have
to have a definition, with an initialization and without extern, in a
source file.

wrote in message
news:0b33492b-c958-4704-b1c4-3dfd2a08685e@a2g2000prm.googlegroups.com...
> On Aug 6, 10:59 am, "S James S Stapleton"
> wrote:
>> wrote in message
>>
>> news:02b0881e-fe86-4293-bdfc-0c2b1b994ffb@r15g2000prd.googlegroups.com...
>> > On Aug 6, 6:47 am, "S James S Stapleton" wrote:
>>
>> >> I was declaring my variables extern in the header, not the C file. I
>> >> added
>> >> extern to my C file for the variables, but now I get an error:
>> >> newdel.cpp:5: warning: 'CHAR_TYPE_' initialized and declared 'extern'
>> >> newdel.cpp:6: warning: 'CHAR_PTR_TYPE_' initialized and declared
>> >> 'extern'
>>
>> >> The relevant lines of code:
>> >> extern type_id CHAR_TYPE_ = -1;
>> >> extern type_id CHAR_PTR_TYPE_ = -1;
>>
>> >> My library now exports these symobls dynamically.
>>
>> > See section 1.7 of the comp.lang.c
>> > FAQ,http://c-faq.com/decl/decldef.html
>> > . Basically, your header file should contain
>>
>> > extern type_id CHAR_TYPE_;
>>
>> > and exactly one of your source files should contain
>>
>> > type_id CHAR_TYPE_ = -1;
>>
>> > outside of any function.
>>
>> Thanks, that's what I thought, but the symbols for my constants didn't
>> show
>> up in the 'nm -D' call on my object (the functions showed up fine),
>> unless I
>> put the 'extern' in the C file. As I said, an extern was also in a .c
>> source
>> file for the system's libc (which came unmodified from the csup of the
>> source tree). So, for some reason, I have to violate that practice to get
>> things to work (and that practice is violated in the OS source as well).
>
> Then something else is wrong. I tried making a shared library the way
> I said and it works fine, and the variable does show up in 'nm -D'.
> Can you post your code, or reduce it to an example that shows the
> problem?
>
> (You *did* recompile and relink everything, right?)
>
>> Very strange. I'd place the blame solely on me if it were just my source
>> acting odd. But the oddities in the system source are really making me
>> wonder.
>
> There is a crucial difference: in the system source example you cite,
> the variable tzname is not explicitly initialized. If you do not want
> to initialize your variable, it is okay to put 'extern type_id
> CHAR_TYPE_;' in your header, and never have an explicit definition
> 'type_id CHAR_TYPE_ = 0;' . The linker will automatically initialize
> it to zero (or for an array, all zeros). But since it appears you
> want the value -1 instead, you can't do this in your program; you have
> to have a definition, with an initialization and without extern, in a
> source file.

Ahh, yes, I looked back again, for some reason I remembered an assignment.
My mistake. Though now I wonder why it only shows up in the dynamic symbol
table with 'extern' in the C file.

On Aug 7, 6:47 am, "S James S Stapleton" wrote:

> Ahh, yes, I looked back again, for some reason I remembered an assignment.
> My mistake. Though now I wonder why it only shows up in the dynamic symbol
> table with 'extern' in the C file.

I do too. It looks like you are on FreeBSD, same as me. Can you make
a small example that shows this behavior?

Which should I do:

1) post the file to the newsgroup
2) post a link to a web file
3) just send it straight to you.

I don't care which, what I send will be either Public Domain'ed or BSD'ed.

Thanks,
-Jim Stapleton

wrote in message
news:adaa5dbb-04bb-46c1-a24d-07b70db3b10f@z11g2000prl.googlegroups.com...
> On Aug 7, 6:47 am, "S James S Stapleton" wrote:
>
>> Ahh, yes, I looked back again, for some reason I remembered an
>> assignment.
>> My mistake. Though now I wonder why it only shows up in the dynamic
>> symbol
>> table with 'extern' in the C file.
>
> I do too. It looks like you are on FreeBSD, same as me. Can you make
> a small example that shows this behavior?

On Aug 11, 7:41 am, "S James S Stapleton"
wrote:
> Which should I do:
>
> 1) post the file to the newsgroup
> 2) post a link to a web file
> 3) just send it straight to you.

If it's relatively short, post it here. If it's longer (more than
100-200 lines) then put it on a web site and post a link. That way
anyone can contribute ideas.

wrote in message
news:9b814a5b-cd5f-4fb6-b164-0dde06661b47@x16g2000prn.googlegroups.com...
> On Aug 11, 7:41 am, "S James S Stapleton"
> wrote:
>> Which should I do:
>>
>> 1) post the file to the newsgroup
>> 2) post a link to a web file
>> 3) just send it straight to you.
>
> If it's relatively short, post it here. If it's longer (more than
> 100-200 lines) then put it on a web site and post a link. That way
> anyone can contribute ideas.

Nevermind. It's working properly now. I must have been doing something
stupid. I wish I knew what I did or why it is fixed now...

-Jim Stapleton