Complicated linking problem

[Erik Leunissen]

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.

[Gordon Burditt]

>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
understandin g 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

[Barry]

"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:11******** *****@corp.supe rnews.com...

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
understandin g 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

[Erik Leunissen]

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
understandi ng 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.

[Mark McIntyre]

On Sat, 10 Dec 2005 10:10:15 +0100, in comp.lang.c , Erik Leunissen
<lo**@the.foote r.invalid> 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 =----