MinGW - Minimalist GNU for Windows

Matt England wrote:
> Why do shared/dynamic library (DLL) builds in mingw/msys with g++ 
> attempt to resolve all references, even for other libraries?
> 
> Linux systems, on the other hand, don't try to resolve all references 
> when building shared-object (.so) files (which I understand have some 
> sort of resemblance to Windows DLLs), but rather the references are 
> resolved at the time the application that uses said libraries is built.
> 
> Eg, when trying to build (within mingw) a library that uses the bzip2 
> module, I get reference errors like this:
> 
> g++ -shared [...a slew of .o files...] libutil.dll
> BZipBufferCompressor.o:BZipBufferCompressor.cpp:(.text+0xb39): undefined 
> reference to `BZ2_bzCompressEnd@...'
> [...]
> 
> How can I avoid this the library-build-time reference errors and instead 
> push the link-time-reference resolution to the time of an application 
> build?  This would also dramatically reduce the size of the .dlls when 
> reference static libraries (presumably).
> 
> Maybe Windows defines DLLs to be freestanding apps, and hence is 
> distinctly different then Linux .so files?  If so, where can I read more 
> about this?
The only way to do what you want would be to make the libraries in question 
  dll files themselves.

At 2/26/2006 04:41 PM, Jonathan Wilson wrote:
>Matt England wrote:
>>Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt 
>>to resolve all references, even for other libraries?
>>Linux systems, on the other hand, don't try to resolve all references 
>>when building shared-object (.so) files (which I understand have some 
>>sort of resemblance to Windows DLLs), but rather the references are 
>>resolved at the time the application that uses said libraries is built.
>>Eg, when trying to build (within mingw) a library that uses the bzip2 
>>module, I get reference errors like this:
>>g++ -shared [...a slew of .o files...] libutil.dll
>>BZipBufferCompressor.o:BZipBufferCompressor.cpp:(.text+0xb39): undefined 
>>reference to `BZ2_bzCompressEnd@...'
>>[...]
>>How can I avoid this the library-build-time reference errors and instead 
>>push the link-time-reference resolution to the time of an application 
>>build?  This would also dramatically reduce the size of the .dlls when 
>>reference static libraries (presumably).
>>Maybe Windows defines DLLs to be freestanding apps, and hence is 
>>distinctly different then Linux .so files?  If so, where can I read more 
>>about this?
>The only way to do what you want would be to make the libraries in 
>question  dll files themselves.

Well, uh, yes.  Isn't that the entire point?  Is not

    dynamic library = dll file = "libraries in question" = libraries I'm making

?

And if so, I guess the question is: how do I make DLL files?  Apparently 
I'm not doing this correctly?

-Matt

> Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt=
=20
> to resolve all references, even for other libraries?

I don't know _why_ mingw does that but this is thge behavior of all
Win32 Compiler I've come across so far. So I'd suspect it is something
inherent to their object/binary format. But others most certainly
are better suited to comment.

> Linux systems, on the other hand, don't try to resolve all references whe=
n=20
> building shared-object (.so) files (which I understand have some sort of=
=20
> resemblance to Windows DLLs), but rather the references are resolved at t=
he=20
> time the application that uses said libraries is built.

Yes, I've noticed that too.

I'm still not sure I do like that though I agree there are pros
as well (beside the cons).

> How can I avoid this the library-build-time reference errors and instead=
=20
> push the link-time-reference resolution to the time of an application=20
> build?  This would also dramatically reduce the size of the .dlls when=20
> reference static libraries (presumably).

You can't avoid that when referencing static libraries. It doesn't
work that way on Linux either. It either dynamic or static but not
dynamically static or so.

Therefor:
static libraries are linked in statically. That's the whole point
of using static libraries. If you wish to resolve the references
dynamically use a shared object (or DLL).

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Michael Gerdau wrote:

> > Why do shared/dynamic library (DLL) builds in mingw/msys with g++ attempt
> > to resolve all references, even for other libraries?
> 
> I don't know _why_ mingw does that but this is thge behavior of all
> Win32 Compiler I've come across so far. So I'd suspect it is something
> inherent to their object/binary format. But others most certainly
> are better suited to comment.

This restriction (that all symbols must be resolved at link time) is a
just a fundamental aspect of how windows works.  The concept of lazy
linking where undefined symbols can be resolved at runtime by the
dynamic linker does not exist on windows.

FWIW windows is not the only platform with this restriction -- I believe
AIX and/or darwin have similar issues.  The libtool list would be able
to give more information.

Brian

At 2/27/2006 12:21 AM, Brian Dessent wrote:
>This restriction (that all symbols must be resolved at link time) is a
>just a fundamental aspect of how windows works.  The concept of lazy
>linking where undefined symbols can be resolved at runtime by the
>dynamic linker does not exist on windows.

Ok, great info.  Are there any sources (preferably "authoritative" ones, 
like from Microsoft) that I can point to for more info and future, 
authoritative reference on this?

Would there be any way around this behavior, like a g++/ld parameter 
option, environment variable setting, etc?  (I'm guessing there is not, 
especially if this is a Windows-OS restriction, but I'm leaving no stone 
unturned.)  As an aside:  when creating the same library(ies)/DLLs (that 
require the resolve-all-symbols-at-link-time problem) as static libraries 
(.a files), there are no link-time symbol-resolution problems.  So at least 
there's some "lazy linking" capability at least on some level.

>FWIW windows is not the only platform with this restriction -- I believe
>AIX and/or darwin have similar issues.  The libtool list would be able
>to give more information.

Ok.  By "libtool list" I assume you mean their users email list.  In any 
case: would libtool help solve my above problems?

Another side (although I may take this up in more detail with the libtool 
folks, but I thought it worth asking here):

I'm trying to learn more about why libtool is useful at all if it doesn't 
solve the above problems.  While skimming 
<http://www.gnu.org/software/libtool/manual.html#Introduction>, I 
realize:  I don't need to write *any* platform-specific code for my 
libraries, shared or not.  Maybe this is because I'm not attempting to link 
them "manually" in the code after an application's startup, I'm just 
letting the linker do this for me?  Is that what that stuff is all 
about?  (Yes, I'm quite ignorant here.)

-Matt

> Would there be any way around this behavior, like a g++/ld parameter=20
> option, environment variable setting, etc?  (I'm guessing there is not,=20
> especially if this is a Windows-OS restriction, but I'm leaving no stone=
=20
> unturned.)  As an aside:  when creating the same library(ies)/DLLs (that=
=20
> require the resolve-all-symbols-at-link-time problem) as static libraries=
=20
> (.a files), there are no link-time symbol-resolution problems.  So at lea=
st=20
> there's some "lazy linking" capability at least on some level.

I'm not quite sure I understand what you are after. However maybe
the following info does help you anyway:

When linking against a DLL the "usual" way is to use an importlib
(Note: gcc/mingw/ld supports directly linking against the DLL without
the need for an importlib; MS VC++ up to version 6 could not do that;
I don't know about MS VC++ version 7).

An importlib basically is a special lib that "claims" the corresponding
DLL does export (at least) the entries the importlib "knows" about.

Wether or not the DLL actually _does_ export those entries is not
checked during linktime. So in a way you do have some sort of lazy
linking as the actual resolving of references is done at runtime on
Windows as well.

Since you could create an importlib without actually having the DLL
you could (technically) achieve a similar thing as on Linux.

Or so.

HTH, best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Solution(never tried):http://edll.sourceforge.net

What I like(in my app(c)):
main_app.c:
__dllexport CFunction(int arg)
{
//implementation here
};

Def file:
LIBRARY MyApp.exe
EXPORTS
CFunction

compile this with gcc using the -Wl,--def-file=3Dyour_def_file
-Wl,--out-implib=3DlibApp.a flags

this will create a library: libApp.a which will allow you to link your dll
back to your main application.

The reason dll's can't do this normally is because in the PE/COFF file
format, a dll is an exe, except the flags tell Windows it is a dll file and
it must contain an export table.

Hope it helps!

On 2/27/06, Michael Gerdau <mgd@...> wrote:
>
> > Would there be any way around this behavior, like a g++/ld parameter
> > option, environment variable setting, etc?  (I'm guessing there is not,
> > especially if this is a Windows-OS restriction, but I'm leaving no ston=
e
> > unturned.)  As an aside:  when creating the same library(ies)/DLLs (tha=
t
> > require the resolve-all-symbols-at-link-time problem) as static
> libraries
> > (.a files), there are no link-time symbol-resolution problems.  So at
> least
> > there's some "lazy linking" capability at least on some level.
>
> I'm not quite sure I understand what you are after. However maybe
> the following info does help you anyway:
>
> When linking against a DLL the "usual" way is to use an importlib
> (Note: gcc/mingw/ld supports directly linking against the DLL without
> the need for an importlib; MS VC++ up to version 6 could not do that;
> I don't know about MS VC++ version 7).
>
> An importlib basically is a special lib that "claims" the corresponding
> DLL does export (at least) the entries the importlib "knows" about.
>
> Wether or not the DLL actually _does_ export those entries is not
> checked during linktime. So in a way you do have some sort of lazy
> linking as the actual resolving of references is done at runtime on
> Windows as well.
>
> Since you could create an importlib without actually having the DLL
> you could (technically) achieve a similar thing as on Linux.
>
> Or so.
>
> HTH, best,
> Michael
> --
> Vote against SPAM - see http://www.politik-digital.de/spam/
> Michael Gerdau       email: mgd@...
> GPG-keys available on request or at public keyserver
>
>
>