Re: OTOH, you folks are smart ...

See below...
On Tue, 18 Sep 2007 12:46:16 -0500, "BobF" <rNfOrSePeAzMe@xxxxxxxxxxx> wrote:

see embedded

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:hppve39lkc02f545pviqnqq336rqpsfanm@xxxxxxxxxx
See below...
On Tue, 18 Sep 2007 08:45:35 -0500, "BobF" <rNfOrSePeAzMe@xxxxxxxxxxx>
wrote:


"Giovanni Dicanio" <giovanni.dicanio@xxxxxxxxxx> wrote in message
news:%23Az2tif%23HHA.1484@xxxxxxxxxxxxxxxxxxxxxxx

"BobF" <rNfOrSePeAzMe@xxxxxxxxxxx> ha scritto nel messaggio
news:u7QHi2e%23HHA.1204@xxxxxxxxxxxxxxxxxxxxxxx

If the DLL_ entry has some important code, that code can be embedded
into a different function (e.g. <SDKName>_Init), to be called by the
SDK
user to initialize the SDK.

It does have important code and it is named as you suggest. If I build
an app with the SDK including the SDK source as part of the app build
everything builds fine. It's when I move the _DLLEntry defining module
to the lib that the problem arises. It appears to be a link order
problem.

Since posting this question I did some more testing. If I remove the
one
_DLLEntry defining module from the lib and included its source in the
project, then everything is fine.

It would be interesting to see what the aforementioned DLL entry
function
does...

I don't know if you may solve the problem linking *dynamically* to
CRT...
(not static linking, but using multithreaded DLLs).
****
Linking dynamically to the CRT has nothing to do with multithreading.
---------------
I agree, linking dynamically isn't specific to multithreading
---------------
****


To get to the point I'm at now, it was necessary to tell the librarian to
remove default lib names from object files to create the static lib and
then
be able to link it in a DLL project.
****
There's something wrong if you have to get rid of all the default lib
names.
---------------
Yep, there's something wrong. My guess is there are two things wrong. 1)
the way the SDK is contructed, and 2) my poor understanding of DLLs vs
static libs
****
There's really very little information here. Assume that you have a single function in
your SDK, void DoSomething(). Then it would probably be in DoSomething.cpp, and you would
link DoSomething.obj into your build. Note that at no time do we see any need whatsoever
for DllMain or any code to be executed before DoSomething() is called. So to make a DLL
from this, you would createa a DLL, it would have a truly trivial DllMain (only returns
TRUE), make the function exported (and if you don't want to change the source code to add
__declspec(dllexport), you could do this in the .def file or the linker command line, and
you're done).

You imply, however, that there is some amount of code that must be executed before
DoSomething() is valid. In that case, the specification of the system would be that
before calling DoSomething(), you would call InitStuff() or some similar name. Now, the
end user who is going to use this library has read the documentation about how to use it,
and knows to call InitStuff(), so all you would do is create a DLL with the same trivial
DllMain, and export DoSomething() and InitStuff(). End of story. Note that the client of
this library does not care in the slightest whether the final application is linked with
DoSomething.obj [which includes InitStuff()] or is linked with DoSomething.lib, the output
library from the DLL build. The client of this library still calls InitStuff(), then can
legitimately call DoSomething().

So what I don't understand is that, given that there is no need to do any implicit
initialization in the library version where the .obj files are linked in explicitly, how
is that you need to do initialization in the DLL? You need to explain this better so we
have some idea what the problem is.
joe
*****
---------------
****

I'm able to use the static lib to build an app with no problems as long as
I
leave the entry-point module out of the static lib and include its source
as
part of the project.
****
Yes, that would be the only correct way; including the entry point in the
static lib would
definitely be an error
--------------
This is the core of my problem. I don't understand why there should be a
difference. Compile it with other sources at compile time, or pull it in
from a lib at link time. Either way there is an object file being linked
with a bunch of other object files to produce the output
****
There shouldn't be. If there is, there's something wrong with the build configuration.
For example debug vs. release, static vs. dynamic, etc.
--------------
****

My current theory is that this allows the entry-point module to be
referenced by the linker *before* the run-time is referenced. The build
log
shows the run-time being referenced, THEN the SDK static lib.
****
Well, that is indeed correct, and that is what is *supposed* to happen.
The DLL has an
entry point function, it is loaded. It has unresolved external
references. It resolves
them. This is how linkers are designed.
--------------
You think?!
****
Absolutely. I've had to maintain linkers, and I've worked with linker source code. I've
been working with linkers for...hmm...44 years. They all work the same way. Only minor
details change. Probably the biggest changes over that time is the notion of Polish
fixups (address computations expressed in interpretable code in the .obj file which is a
reverse-Polish notation (postfix) expression computation that computes the address fixup
for unresolved externals, and the notion of creating import records for dynamic linking.
Otherwise the technology is what was fairly mature by the late 1950s.
joe
--------------
*****


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: OTOH, you folks are smart ...
    ... user to initialize the SDK. ... an app with the SDK including the SDK source as part of the app build ... It would be interesting to see what the aforementioned DLL entry ... I'm able to use the static lib to build an app with no problems as long as ...
    (microsoft.public.vc.mfc)
  • Re: OTOH, you folks are smart ...
    ... for DllMain or any code to be executed before DoSomethingis called. ... to make a DLL ... I am the SDK user. ... *appears* to me to be because of the order the libraries get processed. ...
    (microsoft.public.vc.mfc)
  • Re: OTOH, you folks are smart ...
    ... for DllMain or any code to be executed before DoSomethingis called. ... to make a DLL ... I am the SDK user. ... *appears* to me to be because of the order the libraries get processed. ...
    (microsoft.public.vc.mfc)
  • Re: Kompiler mit Enlosschleife
    ... >Daß das Laufzeitverhalten einer Applikation genauso miserabel ist, ... eigentlich nur in Programmen, die mehr als einen Thread verwalten, oder? ... Nehme ich aber auch aus der Klageschrift raus, externe DLL, ... Aber das aktuelle SDK? ...
    (microsoft.public.de.vb)
  • Re: OTOH, you folks are smart ...
    ... for DllMain or any code to be executed before DoSomething() is called. ... from this, you would createa a DLL, it would have a truly trivial DllMain ... I am the SDK user. ...
    (microsoft.public.vc.mfc)
Loading