Can all functions of a static library be compiled in without any calls

Can a static library be linked in as a resource or something so that all
functions
inside are available even if they are not called by the executable?

Thanks,
Drew

Igor
Thu Jun 22 13:10:18 CDT 2006

Drew <drew.nospam.myers@esrd.com> wrote:
> Can a static library be linked in as a resource or something so that
> all functions
> inside are available even if they are not called by the executable?

Why do you want that? Available in what sense? What is the original
problem you are trying to solve?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Drew
Thu Jun 22 14:06:44 CDT 2006

Igor,

OK. We have an executable version of our program and a DLL version that
encapsulates the functionality of our program that is exposed through a JNI
layer so that it can be programmed using Java. A customer has now requested
that that functionality now be provided through the EXE. So we took the DLL
specific code and made it a static library project that we then link with
the
EXE but since the EXE never actually calls any function in the static
library
they are all optimized away at link time. I know one method would be dummy
calls to all functions i.e. if(0) FunctionCallInLib(); but was hoping to
avoid that.

Thanks,
Drew

"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:efeDDfilGHA.4772@TK2MSFTNGP03.phx.gbl...
> Drew <drew.nospam.myers@esrd.com> wrote:
>> Can a static library be linked in as a resource or something so that
>> all functions
>> inside are available even if they are not called by the executable?
>
> Why do you want that? Available in what sense? What is the original
> problem you are trying to solve?
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>

Igor
Thu Jun 22 14:17:38 CDT 2006

Drew <drew.nospam.myers@esrd.com> wrote:
> A customer has now requested that that functionality now be provided
> through the EXE. So we took the DLL specific code and made it a
> static library project that we then link with the
> EXE but since the EXE never actually calls any function in the static
> library
> they are all optimized away at link time.

Suppose you managed to convince the linker not to remove these
functions. How exactly does your customer plan to use them? You can't
just load an EXE and call an arbitrary function in it, the way you would
with a DLL.

When you say "functionality be provided throught the EXE", in exactly
what way should it be exposed? Embedding a static lib into an EXE does
not make any sense, since there's no way to use it (as in, actually call
functions in it).
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Drew
Thu Jun 22 15:15:09 CDT 2006

It seems that this has become a non-issue as we will have to reference all
the functions (via function pointers) in the EXE anyhow in order to register
them with JVM.

> Suppose you managed to convince the linker not to remove these functions.
> How exactly does your customer plan to use them? You can't just load an
> EXE and call an arbitrary function in it, the way you would with a DLL.

The end user will define an environment variable which points to a Java
class
file. The app launches JVM and the class file executes calling our code via
JNI layer.

Anyhow thanks for your time,
Drew

"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:e3p6GCjlGHA.4268@TK2MSFTNGP05.phx.gbl...
> Drew <drew.nospam.myers@esrd.com> wrote:
>> A customer has now requested that that functionality now be provided
>> through the EXE. So we took the DLL specific code and made it a
>> static library project that we then link with the
>> EXE but since the EXE never actually calls any function in the static
>> library
>> they are all optimized away at link time.
>
> Suppose you managed to convince the linker not to remove these functions.
> How exactly does your customer plan to use them? You can't just load an
> EXE and call an arbitrary function in it, the way you would with a DLL.
>
> When you say "functionality be provided throught the EXE", in exactly what
> way should it be exposed? Embedding a static lib into an EXE does not make
> any sense, since there's no way to use it (as in, actually call functions
> in it).
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>

Tamas
Fri Jun 23 11:39:20 CDT 2006

Drew wrote:
> It seems that this has become a non-issue as we will have to reference all
> the functions (via function pointers) in the EXE anyhow in order to register
> them with JVM.


I don't think the linker optimizes away functions for which you have a
pointer in your code. For example:

void a_function(int)
{
// <--- this function will be linked
}

typedef void (*PtrFunc)(int);

PtrFunc f = a_function; // <--- because it's used here

This pretty much tells the linker that the function is needed, and it
won't be removed. Correct me if I'm wrong, but you don't need additional
calls to that function to convince the linker that it needs to be added
to the EXE. The linker has the right to remove unused functions from the
EXE, but referencing the function's address is just as good as calling it.

I have an application that defines a set of callback functions. They are
never called from my application directly. They were designed to be
called by external plugins (DLLs). I store pointers to these functions
in a structure, and pass that to the DLL, so the plugin can call back to
my program. This alone ensures that the linker includes my functions in
the EXE, without me every calling those functions.

Tom

Drew
Fri Jun 23 13:40:21 CDT 2006


"Tamas Demjen" <tdemjen@yahoo.com> wrote in message
news:ewmGVOulGHA.492@TK2MSFTNGP05.phx.gbl...
> Drew wrote:
>> It seems that this has become a non-issue as we will have to reference
>> all
>> the functions (via function pointers) in the EXE anyhow in order to
>> register
>> them with JVM.
>
>
> I don't think the linker optimizes away functions for which you have a
> pointer in your code. For example:
>
> void a_function(int)
> {
> // <--- this function will be linked
> }
>
> typedef void (*PtrFunc)(int);
>
> PtrFunc f = a_function; // <--- because it's used here

Indeed, you are correct, as I stated this is a non-issue. Problem solved.

Drew

> This pretty much tells the linker that the function is needed, and it
> won't be removed. Correct me if I'm wrong, but you don't need additional
> calls to that function to convince the linker that it needs to be added to
> the EXE. The linker has the right to remove unused functions from the EXE,
> but referencing the function's address is just as good as calling it.
>
> I have an application that defines a set of callback functions. They are
> never called from my application directly. They were designed to be called
> by external plugins (DLLs). I store pointers to these functions in a
> structure, and pass that to the DLL, so the plugin can call back to my
> program. This alone ensures that the linker includes my functions in the
> EXE, without me every calling those functions.
>
> Tom