link problem - HP UX

This is a discussion on link problem - HP UX ; Hi At work I have a problem linking with a shared library, two functions unresolved. nm shows them as "extern|code", but in a little test I did, it seems that nm should also show them as "extern|entry" as well. Is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: link problem

  1. link problem

    Hi

    At work I have a problem linking with a shared library, two functions
    unresolved. nm shows them as "extern|code", but in a little test I did,
    it seems that nm should also show them as "extern|entry" as well.

    Is there any way to force the linker to use the functions in this case?
    E.g., some way of explicitly stating the function names.

    A bientot
    Paul
    --
    Paul Floyd http://paulf.free.fr (for what it's worth)
    Surgery: ennobled Gerald.

  2. Re: link problem

    Paul Floyd writes:

    > At work I have a problem linking with a shared library, two functions
    > unresolved. nm shows them as "extern|code", but in a little test I did,
    > it seems that nm should also show them as "extern|entry" as well.


    These symbols are hidden in the library and are not available for linking.

    > Is there any way to force the linker to use the functions in this case?
    > E.g., some way of explicitly stating the function names.


    The library designer explicitly didn't want you to use these symbols
    (probably because they are private implementation detail).

    You can't call them, unless you implement a really ugly hack
    (involving assembly glue, because on PA-RISC you must set/restore
    %dp (%r27) in addition to %pc when calling across modules).

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

  3. Re: link problem

    On Thu, 12 Oct 2006 20:15:01 -0700, Paul Pluzhnikov
    wrote:
    > Paul Floyd writes:
    >
    >> At work I have a problem linking with a shared library, two functions
    >> unresolved. nm shows them as "extern|code", but in a little test I did,
    >> it seems that nm should also show them as "extern|entry" as well.

    >
    > These symbols are hidden in the library and are not available for linking.


    That's more or less what I thought.

    >> Is there any way to force the linker to use the functions in this case?
    >> E.g., some way of explicitly stating the function names.

    >
    > The library designer explicitly didn't want you to use these symbols
    > (probably because they are private implementation detail).
    >
    > You can't call them, unless you implement a really ugly hack
    > (involving assembly glue, because on PA-RISC you must set/restore
    > %dp (%r27) in addition to %pc when calling across modules).


    The library in question is from a separate division of my employer. The
    functions were supposed to be made public in the current version, but
    for whatever reason, this didn't happen for HP-UX. I was wondering if I
    could force the linker into letting me jump the gun. From what you say,
    this is not easily possible. So I'll just have to wait for the next
    version to be ready.

    Thanks
    Paul
    --
    Paul Floyd http://paulf.free.fr (for what it's worth)
    Surgery: ennobled Gerald.

  4. Re: link problem

    Paul Pluzhnikov wrote:
    : These symbols are hidden in the library and are not available for linking.

    The proper tool is /usr/ccs/bin/odump -slexport.

    : because on PA-RISC you must set/restore
    : %dp (%r27) in addition to %pc when calling across modules).

    You only need to restore R27 if you are using PA64 or MPE/iX.
    For PA32, you mean R19.

+ Reply to Thread