Re: OTOH, you folks are smart ...

See below...
On Wed, 19 Sep 2007 05:06:29 -0500, "BobF" <rNfOrSePeAzMe@xxxxxxxxxxx> wrote:


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

see below

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:n7e0f3thnqd96hv13829m5u3jkfqiuimnf@xxxxxxxxxx
See below...
On Tue, 18 Sep 2007 12:46:16 -0500, "BobF" <rNfOrSePeAzMe@xxxxxxxxxxx>
wrote:

see embedded

<<SNIP>>
****
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
*****

Yeah, I think something got lost along the way.

I am the SDK user. I'm not creating an SDK for others to use. The SDK
provides no libs or DLLs. It is only a (small) collection of cpp & h
files.
****
From your description, this is what I assumed. And apparently what you
are trying to do
is create a DLL that has the functionality of this SDK prepackaged so the
user doesn't
have to compile it inline, and that's what my answer was predicated on.
****

All of the sample apps (DLLs) provided with the SDK simply add the SDK
source files to the sample projects along with the app-specific files.
Everything, SDK and app-specific sources, get compiled together in the
same
build process.
*****
That's what I understood
****

What I am trying to do is to get the SDK source files into a lib, so that
my
app-specific projects will only contain my own app-specific source files,
along with reference to the library to bring in the SDK objects for
linking.
****
That's what I was explaining how to do
****

One of the source files included in the SDK contains the DllMain function.
It is trivial, but does initialize a global pointer with the DLL (app)
instance handle. The SDK also includes a def file ...
*****
This makes no sense. If the SDK is intended to be compiled in an app, it
would not have
any DllMain. If it was intended to be compiled into your own private DLL,
it would not
have any DllMain. So what is DllMain doing? Why does it matter in the
slightest?
****


I created a separate project to build debug and release versions of a
static
library to contain the SDK objects.

If I build an app referencing this library, I get the duplicate
_DllMain@12
error message during linkage.
****
That's because DllMain has no reason to exist if the SDK is just a
collection of .cpp/,h
files.

If I move that contains DllMain out of the library and include it in the
project, the build works fine.
****
If you are building a DLL, this makes sense. If you are not building a
DLL, there's no
reason for DllMain to exist at all, since it makes no sense whatsoever to
have it in a
.exe file. That's what I was trying to explain
****

The whole purpose of the lib I'm creating is to serve as a build-time
tool.
****
The real breakdown here is that you should totally, completely, and
without reservation be
able to totally ignore the existence of the DllMain function. It is
entirely meaningless.

Let's re-examine what I said.

I buy an SDK of some sort. It is intended to be a collection of .cpp/.h
files that I
compile into my app. So I decide that I don't want them compiled into my
project, but
want them in a separate DLL. So I create a DLL project, which has a
essentially empty
DllMain (a placeholder, probably just stores the HINSTANCE parameter if it
does anything
at all), add the .cpp/.h files to this DLL project, remove them from my
old project, build
the DLL, and add the .lib file created from the DLL build to my original
project. End of
story. Done. No problem.

If the source files were INTENDED to build a DLL, then I have been
misusing them by
including them in my build directly, and the DllMain that comes with them
was intended to
be used to build a DLL. In that case, I build the SDK as a DLL, include
its .lib file in
my application.
joe
****

Joe, first let me say "thanks" for hanging in there on this one.

The source files ARE intended to build a DLL. The DLL is the app.
****
No, it isn't. A DLL is a DLL. An app is an app, and is a .exe file. The term "app" can
only apply to something represented as a .exe file.
****

// these DLL apps are plugins
// that get loaded and run by other apps

So, my ultimate target is a DLL. Building this DLL requires DllMain. Like
the other functions & classes in the SDK, DllMain is the same for every DLL
created with the SDK.
****
No, if you want to create something that uses this SDK, you should be creating another DLL
that uses this one.
****

If I provide SDK-DllMain in a source file during the build, all is OK. The
resulting DLL does what it is supposed to do. If I move SDK-DllMain into
the lib, I have problems during the linkage step.
****
If you are creating your own DLL, you would have to remove any DllMain from your DLL
project, and use the DllMain that comes with the SDK. So what I think you are saying is
that you are creating three plugins, P1, P2 and P3. These are created by writing your own
code and then linking with the files F1..Fn which are part of the SDK. In that case, the
correct approach is to delete DllMain from the SDK. Take any important code in it and
create a function InitSDK. You will then call InitSDK from your own DllMain.

But it will not ever be possible to have a DllMain in your SDK and another DllMain in your
DLL source code and expect anything useful to happen. You will *always* get a duplicate
symbol error. Because you did not have a DllMain in your DLL source code (which is a
design error), you got one free because the way the library is built, it assumes that if
you neglected to provide a DllMain you have a coding error. Which you do.
****


Now, this is the concept I'm hung up on:

I can provide SDK-DllMain as long as it is part of source that gets compiled
during the build. This makes SDK-DllMain known to the linker before it
processes LIBCMT(D), which contains its own DllMain.
****
This is because you did not supply your own DllMain. you must have a DllMain loaded from
YOUR modules. You can't load it from some library. This would make about as much sense
as putting main() in a library.
****

The exact same SDK-DllMain as part of a lib doesn't link properly. It
*appears* to me to be because of the order the libraries get processed.
LIBCMT(D) contains a DllMain that apparently gets ignored as long as a
DllMain gets found *before* LIBCMT(D) gets processed. If a different copy
of DllMain shows up *after* LIBCMT(D) has been processed, then the linker
complains of duplicates.
****
It appears that there is a default DllMain that is dropped in. So it's simple. Instead
of compiling a static library which has everything in it, compile a static library and a
..obj file. The .obj file contains DllMain. You have to link that in explicitly. The
real problem is that you really have been trying to violate the basic principles that
guide how linkers work. Linkers work by resolving external symbols. You cannot create a
DLL which does not have a DllMain. And while it is arguable that one is supplied in the
standard libraries, the real problem is that you cannot expect that an
improperly-constructed program will link properly.
joe
*****

I have found no way to make the linker process SDK-lib before it processes
LIBCMT(D) ...




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 ...
    ... 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 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)
  • Re: OTOH, you folks are smart ...
    ... The source files ARE intended to build a DLL. ... An app is an app, ... Building this DLL requires DllMain. ... *appears* to me to be because of the order the libraries get processed. ...
    (microsoft.public.vc.mfc)
  • Re: OTOH, you folks are smart ...
    ... The source files ARE intended to build a DLL. ... Building this DLL requires DllMain. ... created with the SDK. ... *appears* to me to be because of the order the libraries get processed. ...
    (microsoft.public.vc.mfc)
  • SDK not containing correct libraries
    ... After building my platform x86 win CE6, I created a SDK. ... I use this sdk to develop a DLL. ... The link phase need several libraries didn't present in the SDK. ...
    (microsoft.public.windowsce.platbuilder)
Loading