Complicated linking problem

Discussion in 'C Programming' started by Erik Leunissen, Dec 9, 2005.

  1. Hello all,

    I want to distribute a shared library (lets call it "parent.so"), which,
    in turn, is used to create shared libs by invoking the GNU linker (lets
    call these shared libs "child.so").

    When creating "child.so", some code which needs to be incorporated into
    each "child.so" comes from "parent.so" itself. I fully control how
    "parent.so" is built, but the problem is that I want to strip all
    symbols from "parent.so" before distribution.

    I understand that in order to perform the link step for creating a
    "child.so", the linker needs to know at which locations in parent.so
    certain symbols reside. If "parent.so" itself doesn't have this
    information in a regular way,

    Is there any (possibly wild) way to inform the linker about what parts
    of "parent.so" need to be linked with "child.so", if that information
    cannot come the regular way from "parent.so" itself?

    I've been looking into command line options to ld, and some of them seem
    to come close to what I might need (e.g. some let you specify symbols,
    some of them let you specify other files that have symbol information,
    ....). But to be honest, I don't completely understand many of them.

    I have been thinking about:
    - using the link map from the link process that generated "parent.so" as
    a source of information about the location of certain symbols;
    - somehow using the linker command language;
    - ...

    Being unfamiliar with details of the linking process, and not fully
    understanding the command line options, let alone the possibilities that
    the linker command language offers, I'm stuck.

    I'd appreciate very much if someone pointed me to possibly feasible ways
    if these exists; or otherwise be explicit if there is definitely no way
    to do what I want.


    Thanks in advance,

    Erik Leunissen
    --
    leunissen@ nl | Merge the left part of these two lines into one,
    e. hccnet. | respecting a character's position in a line.
     
    Erik Leunissen, Dec 9, 2005
    #1
    1. Advertising

  2. >I want to distribute a shared library (lets call it "parent.so"), which,
    >in turn, is used to create shared libs by invoking the GNU linker (lets
    >call these shared libs "child.so").


    Used *BY WHOM*? You or the thief who is your customer?

    >When creating "child.so", some code which needs to be incorporated into
    >each "child.so" comes from "parent.so" itself. I fully control how
    >"parent.so" is built, but the problem is that I want to strip all
    >symbols from "parent.so" before distribution.


    Why? It's obvious you think your customers are thieves, so why
    sell to them at all?

    A shared library is unusable as a shared library without any symbols.
    If it is your intention that parent.so be used *only* to create
    child.so, the information has to be there somewhere for child.so
    to function.

    >I understand that in order to perform the link step for creating a
    >"child.so", the linker needs to know at which locations in parent.so
    >certain symbols reside. If "parent.so" itself doesn't have this
    >information in a regular way,


    If you provide this information in *ANY* way, the thief who is your
    customer will have it. So why go through all this grief?
    I believe if you provide this information in the form of a link
    map or similar, it is possible for the customer to relink parent.so
    and put back the symbols so they are visible in the normal way.

    It is possible to strip symbols down to the minimum needed to
    make the library function, perhaps only the external function
    call entry points. See the --retain-symbols-file <filename>
    option. You give it a list of necessary symbols, one to a line;
    it deletes all the others. Possibly only the external entry
    points for functions are required, but if you have global data,
    some of that might be needed also.

    >Is there any (possibly wild) way to inform the linker about what parts
    >of "parent.so" need to be linked with "child.so", if that information
    >cannot come the regular way from "parent.so" itself?


    If you are providing this information to the thief to feed to the
    GNU linker, you are providing the information to the thief. Why
    is providing it via some obscure means an improvement on anything?

    >I've been looking into command line options to ld, and some of them seem
    >to come close to what I might need (e.g. some let you specify symbols,
    >some of them let you specify other files that have symbol information,
    >...). But to be honest, I don't completely understand many of them.


    >I have been thinking about:
    >- using the link map from the link process that generated "parent.so" as
    >a source of information about the location of certain symbols;
    >- somehow using the linker command language;
    >- ...
    >
    >Being unfamiliar with details of the linking process, and not fully
    >understanding the command line options, let alone the possibilities that
    >the linker command language offers, I'm stuck.
    >
    >I'd appreciate very much if someone pointed me to possibly feasible ways
    >if these exists; or otherwise be explicit if there is definitely no way
    >to do what I want.


    If you don't want the theives to get your program, DON'T SELL IT!

    Gordon L. Burditt
     
    Gordon Burditt, Dec 9, 2005
    #2
    1. Advertising

  3. Erik Leunissen

    Barry Guest

    OT Re: Complicated linking problem

    "Gordon Burditt" <> wrote in message
    news:...
    > >I want to distribute a shared library (lets call it "parent.so"), which,
    > >in turn, is used to create shared libs by invoking the GNU linker (lets
    > >call these shared libs "child.so").

    >
    > Used *BY WHOM*? You or the thief who is your customer?
    >
    > >When creating "child.so", some code which needs to be incorporated into
    > >each "child.so" comes from "parent.so" itself. I fully control how
    > >"parent.so" is built, but the problem is that I want to strip all
    > >symbols from "parent.so" before distribution.

    >
    > Why? It's obvious you think your customers are thieves, so why
    > sell to them at all?
    >
    > A shared library is unusable as a shared library without any symbols.
    > If it is your intention that parent.so be used *only* to create
    > child.so, the information has to be there somewhere for child.so
    > to function.
    >
    > >I understand that in order to perform the link step for creating a
    > >"child.so", the linker needs to know at which locations in parent.so
    > >certain symbols reside. If "parent.so" itself doesn't have this
    > >information in a regular way,

    >
    > If you provide this information in *ANY* way, the thief who is your
    > customer will have it. So why go through all this grief?
    > I believe if you provide this information in the form of a link
    > map or similar, it is possible for the customer to relink parent.so
    > and put back the symbols so they are visible in the normal way.
    >
    > It is possible to strip symbols down to the minimum needed to
    > make the library function, perhaps only the external function
    > call entry points. See the --retain-symbols-file <filename>
    > option. You give it a list of necessary symbols, one to a line;
    > it deletes all the others. Possibly only the external entry
    > points for functions are required, but if you have global data,
    > some of that might be needed also.
    >
    > >Is there any (possibly wild) way to inform the linker about what parts
    > >of "parent.so" need to be linked with "child.so", if that information
    > >cannot come the regular way from "parent.so" itself?

    >
    > If you are providing this information to the thief to feed to the
    > GNU linker, you are providing the information to the thief. Why
    > is providing it via some obscure means an improvement on anything?
    >
    > >I've been looking into command line options to ld, and some of them seem
    > >to come close to what I might need (e.g. some let you specify symbols,
    > >some of them let you specify other files that have symbol information,
    > >...). But to be honest, I don't completely understand many of them.

    >
    > >I have been thinking about:
    > >- using the link map from the link process that generated "parent.so" as
    > >a source of information about the location of certain symbols;
    > >- somehow using the linker command language;
    > >- ...
    > >
    > >Being unfamiliar with details of the linking process, and not fully
    > >understanding the command line options, let alone the possibilities that
    > >the linker command language offers, I'm stuck.
    > >
    > >I'd appreciate very much if someone pointed me to possibly feasible ways
    > >if these exists; or otherwise be explicit if there is definitely no way
    > >to do what I want.

    >
    > If you don't want the theives to get your program, DON'T SELL IT!
    >
    > Gordon L. Burditt


    While to some degree I concur with GLB. Some things fall into the category
    of "locks keep honest men honest, and thieves find another home."

    barry
     
    Barry, Dec 9, 2005
    #3
  4. Gordon Burditt wrote:
    >
    > If you provide this information in *ANY* way, the thief who is your
    > customer will have it. So why go through all this grief?
    > I believe if you provide this information in the form of a link
    > map or similar, it is possible for the customer to relink parent.so
    > and put back the symbols so they are visible in the normal way.
    >


    I do not intend to provide the necessary information to the user. I do
    intend to provide the information to the the linker program. The idea is
    that the linker is called without user intervention by an application
    that I provide. Since I build the application myself, I believe to have
    much more control over the linker invocation than if I were to leave the
    invocation directly to the user.


    > It is possible to strip symbols down to the minimum needed to
    > make the library function, perhaps only the external function
    > call entry points. See the --retain-symbols-file <filename>
    > option. You give it a list of necessary symbols, one to a line;
    > it deletes all the others. Possibly only the external entry
    > points for functions are required, but if you have global data,
    > some of that might be needed also.
    >


    thanks

    >
    >>Is there any (possibly wild) way to inform the linker about what parts
    >>of "parent.so" need to be linked with "child.so", if that information
    >>cannot come the regular way from "parent.so" itself?

    >
    >
    > If you are providing this information to the thief to feed to the
    > GNU linker, you are providing the information to the thief. Why
    > is providing it via some obscure means an improvement on anything?
    >


    see explanation above, please.


    >
    >>I've been looking into command line options to ld, and some of them seem
    >>to come close to what I might need (e.g. some let you specify symbols,
    >>some of them let you specify other files that have symbol information,
    >>...). But to be honest, I don't completely understand many of them.

    >
    >
    >>I have been thinking about:
    >>- using the link map from the link process that generated "parent.so" as
    >>a source of information about the location of certain symbols;
    >>- somehow using the linker command language;
    >>- ...
    >>
    >>Being unfamiliar with details of the linking process, and not fully
    >>understanding the command line options, let alone the possibilities that
    >>the linker command language offers, I'm stuck.
    >>
    >>I'd appreciate very much if someone pointed me to possibly feasible ways
    >>if these exists; or otherwise be explicit if there is definitely no way
    >>to do what I want.

    >
    >
    > If you don't want the theives to get your program, DON'T SELL IT!
    >
    > Gordon L. Burditt


    --
    leunissen@ nl | Merge the left part of these two lines into one,
    e. hccnet. | respecting a character's position in a line.
     
    Erik Leunissen, Dec 10, 2005
    #4
  5. On Sat, 10 Dec 2005 10:10:15 +0100, in comp.lang.c , Erik Leunissen
    <> wrote:

    >Gordon Burditt wrote:
    >>
    >> If you provide this information in *ANY* way, the thief who is your
    >> customer will have it. So why go through all this grief?
    >> I believe if you provide this information in the form of a link
    >> map or similar, it is possible for the customer to relink parent.so
    >> and put back the symbols so they are visible in the normal way.
    >>

    >
    >I do not intend to provide the necessary information to the user. I do
    >intend to provide the information to the the linker program. The idea is
    >that the linker is called without user intervention by an application
    >that I provide. Since I build the application myself, I believe to have
    >much more control over the linker invocation than if I were to leave the
    >invocation directly to the user.


    I think Gordon's point was that no matter how many levels of
    indirection you put this through, the CD or whatever that you send
    your customer will have to contain the linker and the information it
    needs. So your customer has it.

    As has been said already, if you don't want thieves to have your
    software, don't make it available to customers...

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Dec 10, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marius Vollmer
    Replies:
    6
    Views:
    833
    Jim Lewis
    Dec 10, 2003
  2. Henrry Pires

    Stange and complicated

    Henrry Pires, Feb 7, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    389
    Karl Seguin [MVP]
    Feb 7, 2006
  3. Replies:
    0
    Views:
    396
  4. Freshman_in_C_Programming

    Basic but complicated problem....Help me Plz!!!

    Freshman_in_C_Programming, Feb 1, 2006, in forum: C Programming
    Replies:
    24
    Views:
    771
    Ed Prochak
    Feb 6, 2006
  5. Michael T. Richter
    Replies:
    6
    Views:
    151
    Michael T. Richter
    Jul 16, 2008
Loading...

Share This Page