Hiding symbols in shared library - HP UX

This is a discussion on Hiding symbols in shared library - HP UX ; I would like to link a shared library and only make the symbols to be exported as global. By this I mean that I want to override the default settings and mark most of the symbols local. Thus I do ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Hiding symbols in shared library

  1. Hiding symbols in shared library

    I would like to link a shared library and only make the symbols to be
    exported as global.
    By this I mean that I want to override the default settings and mark most of
    the symbols local.

    Thus I do the following:

    g++ -mlp64 temp/file.o -o
    temp/libfoobar.so -static-libgcc -shared -Wl,+hideallsymbols -Wl,-e -Wl,A -Wl,-e
    -Wl,B

    However I end up in ALOT of warnings by the linker for all the undefined
    symbols.
    Is there any other way to acomplish this? Lots of other linkers (sun, linux,
    aix etc.) accept a script file which allows one to write the nessecary
    symbols into but it doens't seem like hp ld provides this option.

    Thanks in advance.

    -- Henrik



  2. Re: Hiding symbols in shared library

    > Is there any other way to acomplish this? Lots of other linkers (sun, linux,
    > aix etc.) accept a script file which allows one to write the nessecary
    > symbols into but it doens't seem like hp ld provides this option.


    Sure, the -c option does that :

    -c filename Read ld options from a file. Each line
    contains
    zero or more arguments separated by white
    space.
    Each line in the file, including the last
    line,
    must end with a newline character. A #
    character
    implies that the rest of the line is a
    comment.
    To escape a # character, use the sequence ##.

    Note that the file is a list of options, not symbols to be hidden. You
    need to put -h
    ahead of every symbol name you want to hide.


    - Carl Burch

    HP WDB Team


  3. Re: Hiding symbols in shared library


    > Sure, the -c option does that :


    > Note that the file is a list of options, not symbols to be hidden. You
    > need to put -h
    > ahead of every symbol name you want to hide.


    So you're saying I should combine this with 'nm' utility to filter out all
    the symbols I want to hide and then make them into a list which is written
    into a file?
    I must say that I understand what needs to be done but it's not trivial.
    Perhaps it's just the lack of my scripting skills. All this because ld
    doesn't support similar features as ld on almost all other platforms.

    An example would be nice.

    -- Henrik



  4. Re: Hiding symbols in shared library

    Henrik-

    > So you're saying I should combine this with 'nm' utility to filter out all
    > the symbols I want to hide and then make them into a list which is written
    > into a file?


    That's what I thought you were asking for. My apologies for not
    understanding your question on the first try.

    > I must say that I understand what needs to be done but it's not trivial.
    > Perhaps it's just the lack of my scripting skills. All this because ld
    > doesn't support similar features as ld on almost all other platforms.
    >
    > An example would be nice.


    I agree. Can you say exactly which linker option on which
    operating system gives the feature you want? Quoting the man page for
    that option would help, as I may not have access to the type of system
    you cite.


    - Carl Burch

    HP WDB Team


  5. Re: Hiding symbols in shared library

    > I agree. Can you say exactly which linker option on which
    > operating system gives the feature you want? Quoting the man page for
    > that option would help, as I may not have access to the type of system
    > you cite.


    For instance on linux we have linker scripts:

    http://unixhelp.ed.ac.uk/CGI/man-cgi?ld

    Notice the switch --version-script. This is a good one because I can create
    simple scripts like:

    mylib

    {

    global:


    symbolA;

    symbolB;

    symbolC;

    local:

    *;

    };



    Notice how much easier this is then the hp linker. I only would have to
    specify what I want to be exported instead of saying everything that I don't
    want to have exported. Naturally this list is much smaller.

    The next problem is that I need to find which symbols to hide. Some
    additional processing to 'nm' output is therefore needed and it is a little
    bit tricky to ensure that I don't miss any symbols.

    More advice is really welcome on this issue. I wouldn't have imagined that
    it would be so tricky to do something really simple.

    After all I cannot be the first man in the world who wanted to create a
    shared library with known exports, right?



    Thanks in advance.

    -- Henrik



  6. Re: Hiding symbols in shared library

    Henrik Goldman wrote:
    > > I agree. Can you say exactly which linker option on which
    > > operating system gives the feature you want? Quoting the man page for
    > > that option would help, as I may not have access to the type of system
    > > you cite.

    >
    > For instance on linux we have linker scripts:
    >
    > http://unixhelp.ed.ac.uk/CGI/man-cgi?ld
    >
    > Notice the switch --version-script. This is a good one because I can create
    > simple scripts like:
    >
    > mylib
    >
    > {
    >
    > global:
    >
    >
    > symbolA;
    >
    > symbolB;
    >
    > symbolC;
    >
    > local:
    >
    > *;
    >
    > };


    Thanks for the URL, that makes it clear that what you're talking
    about is the aside in the Linux ld(1) man page :

    You can also use the version script to control what symbols
    should
    be added to the dynamic symbol table if the output format supports
    it. See the description of --version-script in @ref{VERSION}.

    So what you're concerned about is whether the symbols are added to the
    default
    export list or subtracted from them. In my original answer I
    inadvertantly gave
    you the subtractive answer, while you wanted the additive option. On
    HP-UX that's :

    +e symbol When building a shared library or program,
    mark
    the symbol for export to the dynamic loader.
    Only
    symbols explicitly marked are exported. When
    building a shared library, calls to symbols
    that
    are not exported are resolved internally.

    If you use the +e or +ee option with -B
    symbolic,
    references to the symbol specified are
    resolved
    internally if defined. The runtime behavior
    may
    be different from using +e alone.

    You can specify more than one symbol on the
    command line with multiple option-symbol
    pairs,
    that is, each symbol you specify must be
    preceded
    by the +e option.


    There's also the +ee option, with slightly different semantics with
    regard to whether it changes the default export behavior. It sounds
    more like the Linux feature you cite, since it leaves the default
    exported symbol list in place, while +e empties the list before adding
    the symbol(s) you want. Which behavior is better depends on whether
    you want tight control or still want to default some symbols' behavior.

    Once you start playing with symbol visibility you're likely to have
    to figure out symbols that are added by the implementation, so +e is
    probably a better choice. I highly recommend the "HP-UX Linker and
    Library User's Guide" at http://docs.hp.com/en/B2355-90655/index.html.


    - Carl Burch

    HP WDB Team


  7. Re: Hiding symbols in shared library


    > Once you start playing with symbol visibility you're likely to have
    > to figure out symbols that are added by the implementation, so +e is
    > probably a better choice. I highly recommend the "HP-UX Linker and
    > Library User's Guide" at http://docs.hp.com/en/B2355-90655/index.html.
    >
    >


    Great thanks! All problems are solved. I read the manual and used +e as you
    explained. Now the only global symbols are the ones that I specify and the
    unresolved ones.

    Here is what I wrote for the g++ frontend linker:

    LDFLAGS += -shared -Wl,+e -Wl,A -Wl,+e -Wl,B -Wl,+e -Wl,C ...

    -- Henrik



  8. Re: Hiding symbols in shared library

    Henrik Goldman wrote:
    > After all I cannot be the first man in the world who wanted to create a
    > shared library with known exports, right?


    Use the __declspec directives in the source to explicitely mark your
    exports, then use the command line options to hide the rest.

    It is supported by not-too-old aCC (PA and IPF it seems), gcc and
    is standard in the Microsoft world.

    From a quick google "site:docs.hp.com __declspec":
    ----------------------------------
    o Support for _declspec

    This release supports __declspec(dllimport) and
    __declspec(dllexport) as keywords. These keywords have the same
    semantics as in Microsoft Windows compilers and ease porting of
    applications developed in Microsoft Windows compilers to HP-UX
    systems.

    Support of these keywords enhances the performance of shared libraries
    and relieves the usage of HP_DEFINED_EXTERNAL pragmas and
    +Oextern= list to hide the non-exported symbols.

    Syntax & Semantics:

    __declspec ( extended-attribute ) declarator

    extended-attribute:
    dllimport
    | dllexport

    1. Declaring a symbol with external linkage as __declspec(dllexport)
    tells the compiler that the symbol should be exported from the
    current load module (shared library) and made visible to other
    load modules.

    2. Declaring a symbol with external linkage as __declspec(dllimport)
    tells the compiler that the symbol is defined in a shared
    library and is outside the current load module.

    3. Declaring a class with either the __declspec(dllexport) or
    __declspec(dllimport) keyword results in all its member functions
    and static data members being marked for export or import.

    4. Only symbols having external linkage can be declared using these
    keywords.

    5. It is legal to selectively specify members of a class as dllexport
    or dllimport but selective specification is not allowed if the
    class itself is exported or imported.
    ----------------------------------

    Eric

  9. Re: Hiding symbols in shared library

    Henrik Goldman wrote:
    >> Once you start playing with symbol visibility you're likely to have
    >> to figure out symbols that are added by the implementation, so +e is
    >> probably a better choice. I highly recommend the "HP-UX Linker and
    >> Library User's Guide" at http://docs.hp.com/en/B2355-90655/index.html.
    >>
    >>

    >
    > Great thanks! All problems are solved. I read the manual and used +e as you
    > explained. Now the only global symbols are the ones that I specify and the
    > unresolved ones.
    >
    > Here is what I wrote for the g++ frontend linker:
    >
    > LDFLAGS += -shared -Wl,+e -Wl,A -Wl,+e -Wl,B -Wl,+e -Wl,C ...


    Alternatively (instead of multiple -Wl ..) you can pass
    all the `ld` options in file (see -c filename in ld(1)).

    --vishwas.

  10. Re: Hiding symbols in shared library

    Henrik Goldman wrote:
    : Here is what I wrote for the g++ frontend linker:
    : LDFLAGS += -shared -Wl,+e -Wl,A -Wl,+e -Wl,B -Wl,+e -Wl,C ...

    Generally you should not separate ld options and their args with separate
    -Wls. Combine them: -Wl,+e,A -Wl,+e,B -Wl,+e,C

    (Of course you can go crazy by combining them into all one -Wl. ;-)

    Note: Typically using tricky ld options like +e and -h is very dangerous for
    C++ since it may hide the C++ metadata. All sorts of problems can happen
    with aC++.

+ Reply to Thread