exported symbols - Unix

This is a discussion on exported symbols - Unix ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: exported symbols

  1. exported symbols

    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.

    Is this to be expected? Why?

    Given that the symbols in this library should be accessible to most
    programs, I take it there is a more reliable method of inspecting symbols in
    a library that what this program uses? I would expect it to be in dlfcn -
    but it isn't. Is it safe to assume this is OS specific within the realm of
    *NIX and not part of a general POSIX/*NIX API standard?

    Thanks,
    -Jim








  2. Re: exported symbols

    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.

  3. Re: exported symbols

    "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.

  4. Re: exported symbols


    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



  5. Re: exported symbols

    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.



  6. Re: exported symbols


    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.




  7. Re: exported symbols

    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.

  8. Re: exported symbols


    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.



  9. Re: exported symbols

    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?

  10. Re: exported symbols

    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?




  11. Re: exported symbols

    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.

  12. Re: exported symbols


    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



+ Reply to Thread