MinGW existing DLL linking

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

MinGW existing DLL linking

Clive McCarthy
This is a resend -- it's unclear whether my connection to the mailing list
has 'taken'.


----- Original Message -----
From: "Clive McCarthy" <[hidden email]>
To: <[hidden email]>
Sent: Monday, August 24, 2009 9:36 AM
Subject: MinGW existing DLL linking


> I'm stuck trying to link to three DLLs for jpeg, tiff and OpenGL Glut
> purposes. I have the code working on Ubuntu and I also have a Borland
> version working on XP. I want to recreate the Ubuntu build environment for
> my code on XP using gcc etc. The version of MinGW is a fresh download
> (August 2009).
>
> I have tried the following approach: The first task was to create a set of
> import libraries from the Win XP DLLs using pexports (version 0.42) to
> make a def file and then use the dlltool (version 2.19.1) to perform the
> creation of the import library itself. I found many suggestions for this
> method on the web.
>
> This process looks like this:
>
>        pexports libtiff3.dll > libtiff3.def
>        dlltool -d libtiff3.def -D libtiff3.dll -l libtiff3.a [try -A -k -U
> ??? -- only eight combinations!]
>
> I have tried this latter step with and without the -k option and the -U
> option to kill the @<integer> stuff and delete extra underscores and
> the -A option and the -e option. I have to admit this seems all somewhat
> hokey since pexports isn't part of MinGW and the -k -U -A options seem
> like a skuzzy kludge and not an elegant solution. My impression is that
> dlltool is designed to do too much or too little. If pexports can find the
> exported symbols then dlltool should be able to find them too. The -z
> option from dlltools reveals no symbols.
>
> The documentation from
> http://oldwiki.mingw.org/index.php/CreateImportLibraries has the following
> advice:
>
>               "Depending on the DLL you may want to try one or more of the
> following ...
>               For a detailed description of these options and dlltool take
> a look at the corresponding documentation."
>
> -- which certainly suggests that something is very wrong and of course
> there is no explanatory documentation.
>
> Help please. I have been at this for several days...
> Clive McCarthy


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Tor Lillqvist
>> I'm stuck trying to link to three DLLs for jpeg, tiff and OpenGL Glut
>> purposes.

>> I have tried the following approach: The first task was to create a set of
>> import libraries from the Win XP DLLs

What *the* Win XP DLLs? There are no jpeg, tiff or glut libraries
supplied with Windows XP. At least not ones whose API would correspond
to the "normal" libraries as typically used on Linux and other Unixes.
(Of course also Windows contains code to read jpeg and tiff files, but
it is offered through a quite different public API (part of GDI+, and
maybe there are others).)

If you happen to find such DLLs in the windows\system32 folder on your
machine, it is because some misguided installer for some 3rd-party
software has installed them there at some point in history, which is a
wrong thing to do.

There are several Windows binary distributions of at least libjpeg and
libtiff that come with import libraries directly suitable for use by
MinGW. No need to build the import library yourself. One well-known
site that distributes such is gnuwin32.sourceforge.net. It shouldn't
be hard to find a Windows build of glut that includes a gcc-style
import library either.

--tml

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy
Tor,
Thank you for the response.

The DLLs are not literally XP DLLs but ones obtained in just the manner you
describe.The glut one if from Mark J. Kilgard's website and is likely from a
Microsoft's C compiler. The jpeg & tiff DLLs were obtained from the libjpeg
and libtiff websites. The import libraries for both of these DLLs are also
in Microsoft format but it has been easy to convert these to Borland format
using a simple tool that is part of the Borland software suite. As I
understand things, a DLL for XP is generic, so creating an import library
from one should work nomatter what tool created the DLL?

Can you comment on why dlltool doesn't work as it is supposed to? The
explanation of how it is supposed to work that I read is at:

             http://oldwiki.mingw.org/index.php/CreateImportLibraries

In desperation I have tried all sixteen combinations.:

        pexports libtiff3.dll > libtiff3.def
// to create the .def file, which has the required symbols

        dlltool -d libtiff3.def -D libtiff3.dll -l libtiff3.a
// with -A -k -U options in ALL possible combinations

                and

        dlltool -d libtiff3.def -D libtiff3.dll -e libtiff3.a             //
with -A -k -U options in ALL possible combinations

All result in undefined references during linking.

Clive.


----- Original Message -----
From: "Tor Lillqvist" <[hidden email]>
To: "MinGW Users List" <[hidden email]>
Sent: Monday, August 24, 2009 12:17 PM
Subject: Re: [Mingw-users] MinGW existing DLL linking


>>> I'm stuck trying to link to three DLLs for jpeg, tiff and OpenGL Glut
>>> purposes.
>
>>> I have tried the following approach: The first task was to create a set
>>> of
>>> import libraries from the Win XP DLLs
>
> What *the* Win XP DLLs? There are no jpeg, tiff or glut libraries
> supplied with Windows XP. At least not ones whose API would correspond
> to the "normal" libraries as typically used on Linux and other Unixes.
> (Of course also Windows contains code to read jpeg and tiff files, but
> it is offered through a quite different public API (part of GDI+, and
> maybe there are others).)
>
> If you happen to find such DLLs in the windows\system32 folder on your
> machine, it is because some misguided installer for some 3rd-party
> software has installed them there at some point in history, which is a
> wrong thing to do.
>
> There are several Windows binary distributions of at least libjpeg and
> libtiff that come with import libraries directly suitable for use by
> MinGW. No need to build the import library yourself. One well-known
> site that distributes such is gnuwin32.sourceforge.net. It shouldn't
> be hard to find a Windows build of glut that includes a gcc-style
> import library either.
>
> --tml
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) Thread hijacking
> 3) HTML/MIME encoded mail
> 4) Improper quoting
> 5) Improper trimming
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy
A supplemental comment: the DEF files contain symbols that are _exactly_ the
ones that fail to link as undefined references. The dlltool does not
complain that they are not found in the DLLs -- so I presume they are found.
The symbol names are entirely familiar to me since I have used these DLLs a
good deal in others ports of the software.

This is very frustrating because there really isn't much in an import
library beyond something to satisfy the linker with a set of symbolic names
and data to set-up the dynamic linking. There is most likely some simple
switch I am overlooking.
The  http://oldwiki.mingw.org/index.php/CreateImportLibraries
instructions seem to deal with what I want to do, but don't work.

Does the linker need a reference to both the import library _and_ the DLL?
This is not what other linkers require.


>
> The DLLs are not literally XP DLLs but ones obtained in just the manner
> you
> describe.The glut one is from Mark J. Kilgard's website and is likely from
> a
> Microsoft's C compiler. The jpeg & tiff DLLs were obtained from the
> libjpeg
> and libtiff websites. The import libraries for both of these DLLs are also
> in Microsoft format but it has been easy to convert these to Borland
> format
> using a simple tool that is part of the Borland software suite. As I
> understand things, a DLL for XP is generic, so creating an import library
> from one should work nomatter what tool created the DLL?
>
> Can you comment on why dlltool doesn't work as it is supposed to? The
> explanation of how it is supposed to work that I read is at:
>
>             http://oldwiki.mingw.org/index.php/CreateImportLibraries
>
> In desperation I have tried all sixteen combinations.:
>
>        pexports libtiff3.dll > libtiff3.def
> // to create the .def file, which has the required symbols
>
>        dlltool -d libtiff3.def -D libtiff3.dll -l libtiff3.a
> // with -A -k -U options in ALL possible combinations
>
>                and
>
>        dlltool -d libtiff3.def -D libtiff3.dll -e libtiff3.a
> // with -A -k -U options in ALL possible combinations
>
> All result in undefined references during linking.
>
> Clive.
>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Tor Lillqvist
In reply to this post by Clive McCarthy
> The DLLs are not literally XP DLLs but ones obtained in just the manner you describe.

OK, sorry;)

> The glut one if from Mark J. Kilgard's website and is likely from a
> Microsoft's C compiler. The jpeg & tiff DLLs were obtained from the libjpeg
> and libtiff websites.

What websites, exactly? "libjpeg.org" for instance (don't bother
clicking) seems to be grabbed by a domain squatter. ijg.org (which is
by the official source of libjpeg as far as I know) only has the
source code, as far as I can see. And libtiff.org links to the
gnuwin32 site I mentioned for Windows binaries, and gnuwin32 does
provide an import library for mingw. (As they do for their build of
libjpeg.)

If the glut you use comes with a MS import library (foo.lib), you
could try just copying that to foo.dll.a. Sometimes (for code compiled
with old enough MS C compilers?) that should work, as the format of
object files and import libraries should be the same in Microsoft C
and mingw.

> The import libraries for both of these DLLs are also
> in Microsoft format but it has been easy to convert these to Borland format
> using a simple tool that is part of the Borland software suite. As I
> understand things, a DLL for XP is generic, so creating an import library
> from one should work nomatter what tool created the DLL?

Yes, DLLs are the same format for all (32-bit) Windows versions. (Of
course, a DLL might import functions from system DLLs that are not
present on all versions of Windows, but that is another issue not
related to the format as such.) Note that the calling convention of
functions in a DLL is not indicated in any way (which is kinda
unfortunate and illogical, I think). To get the calling convention
right you need also correct headers and correct magic options when
generating the import library if you do it afterwards.

 > Can you comment on why dlltool doesn't work as it is supposed to?

Sorry, without spedning too much time and looking at the exact same
DLLs you are trying to use, no, and my main point has been that for
libraries like these, why not just use packages that already come with
suitable import libraries?

--tml

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy
mea culpa.
I found the source of my misery. I have been simultaneously using both
the -d and -D inputs to dlltool.

To produce a good import library from a DLL it is necessary to provide
_only_ the DEF file. If both the DEF and the DLL are provided then the
result is not useful. I mistakenly thought that the import library would
contain some more than just a list of symbols and the name of the DLL.

        pexports libtiff3.dll > libtiff3.def
        dlltool -d libtiff3.def -D libtiff3.dll -l libtiff3.a     // wrong
        dlltool -d libtiff3.def  -l libtiff3.a                        //
right



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Ross Ridge
In reply to this post by Clive McCarthy
Clive McCarthy writes:
> ... The import libraries for both of these DLLs are also in Microsoft
>format but it has been easy to convert these to Borland format using a
>simple tool that is part of the Borland software suite.

MinGW uses same the PE-COFF library format as Microsoft, so you should
just able to the import libraries as is without conversion.  It doesn't
support the OMF format used by Borland.  MinGW can also use the DLL
itself as if it were an import libray, so there's no need to play around
with dlltool.

                                        Ross Ridge


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy
Thanks, those are VERY good things to know. I really did spend three days
attempting to get an import library extracted from the DLLs. I succeeded
only when I reverted to the simplest use of dlltool.

        dlltool -d filename.def -l filename.a    // is good

        dlltool -D filename.dll -d filename.def -l filename.a    // does NOT
work -- though I suspect it should

I stumbled upon nothing that suggested I could directly use the Microsoft
import libraries -- I assumed they would be quite incompatible. I had only a
primitive notion of what is in an import library and I figured that dlltool
actually had to do something with the contents of the DLL itself  (it is
called 'dlltool' after all). Now I realise it just keeps the linker happy
and that even the name of the DLL is given to dlltool by the DEF file.

I used PExports to extract the symbols for the DEF file and wondered why it
wasn't part of the MingGW utilities -- but I guess, if one is already
familiar with the contents of DEF files, that it's easy enough to edit up
such a file from the list of undefined references emitted by the linker. As
a convenience for novice users, an enhancement to dlltool would be to read a
DLL and output _both_ a DEF (for reference purposes) and an import library
in a single step.

But then again, better documentation of how and when to create import
libraries would have solved the problem.

Clive.

----- Original Message -----
From: "Ross Ridge" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, August 26, 2009 7:58 AM
Subject: Re: [Mingw-users] MinGW existing DLL linking


> Clive McCarthy writes:
>> ... The import libraries for both of these DLLs are also in Microsoft
>>format but it has been easy to convert these to Borland format using a
>>simple tool that is part of the Borland software suite.
>
> MinGW uses same the PE-COFF library format as Microsoft, so you should
> just able to the import libraries as is without conversion.  It doesn't
> support the OMF format used by Borland.  MinGW can also use the DLL
> itself as if it were an import libray, so there's no need to play around
> with dlltool.
>
> Ross Ridge


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Roger Pack
> I used PExports to extract the symbols for the DEF file and wondered why it
> wasn't part of the MingGW utilities -- but I guess, if one is already
> familiar with the contents of DEF files, that it's easy enough to edit up
> such a file from the list of undefined references emitted by the linker. As
> a convenience for novice users, an enhancement to dlltool would be to read a
> DLL and output _both_ a DEF (for reference purposes) and an import library
> in a single step.
>
> But then again, better documentation of how and when to create import
> libraries would have solved the problem.

Perhaps there's a wiki you could update to help the rest of us :)
-r

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy
In reply to this post by Clive McCarthy

I've had a most excellent dinner so I'm in the mood for musing.
 
I came to the task of linking to an existing DLL full of ignorance and now, with a little knowledge...
 
I decided to put the building of the import libraries in my makefile (why? you might well ask). The libtiff and libjpeg processing work fine. I'm using pexports and dlltool to do the work. You may consider this rather prissy -- it's not as if the DLLs are going to change -- it's more a way of documenting how the all pieces all fit together.
 
The glut library is a different story. Fortunately I found a pre-processed libglut3win.a on the web made by someone at Worcester Polytechnic:
http://web.cs.wpi.edu/~gogo/courses/mingw/
 
My code works fine with this import library, but of course I'm puzzled why what works for jpeg & tiff DLL libraries, doesn't work for glut DLL.
 
The nub of the problem is that the glut DLL has no __stdcall decoration in the DEF file extracted from the DLL by pexports (the horrid @ stuff) but the standard glut header specifies __stdcall so the linking fails.
The glut DLL is from Nate Robins' GLUT for Win32:
http://www.xmission.com/~nate/glut.html
 
There is, for me, a good explanation & explication of these ugly calling convention decorations at:
http://wyw.dcweb.cn/stdcall.htm
 
So I begin to think that dlltool should be able to read header files to add the necessary __stdcall decorations...
 
I could, of course, hand-edit the DEF file but that's hardly a well documented mechanism -- so I might as well use the libglut3win.a I found on the web.
 
So next, I have to tackle freeglut...
 
Does anyone have a nice MinGW libfreeglut.DLL and libfreeglutwin.a ?
 
Clive.

----------------------------------------

> From: [hidden email]
> To: [hidden email]
> Date: Wed, 26 Aug 2009 08:57:03 -0700
> Subject: Re: [Mingw-users] MinGW existing DLL linking
>
> Thanks, those are VERY good things to know. I really did spend three days
> attempting to get an import library extracted from the DLLs. I succeeded
> only when I reverted to the simplest use of dlltool.
>
> dlltool -d filename.def -l filename.a // is good
>
> dlltool -D filename.dll -d filename.def -l filename.a // does NOT
> work -- though I suspect it should
>
> I stumbled upon nothing that suggested I could directly use the Microsoft
> import libraries -- I assumed they would be quite incompatible. I had only a
> primitive notion of what is in an import library and I figured that dlltool
> actually had to do something with the contents of the DLL itself (it is
> called 'dlltool' after all). Now I realise it just keeps the linker happy
> and that even the name of the DLL is given to dlltool by the DEF file.
>
> I used PExports to extract the symbols for the DEF file and wondered why it
> wasn't part of the MingGW utilities -- but I guess, if one is already
> familiar with the contents of DEF files, that it's easy enough to edit up
> such a file from the list of undefined references emitted by the linker. As
> a convenience for novice users, an enhancement to dlltool would be to read a
> DLL and output _both_ a DEF (for reference purposes) and an import library
> in a single step.
>
> But then again, better documentation of how and when to create import
> libraries would have solved the problem.
>
> Clive.
>
> ----- Original Message -----
> From: "Ross Ridge"
> To:
> Sent: Wednesday, August 26, 2009 7:58 AM
> Subject: Re: [Mingw-users] MinGW existing DLL linking
>
>
>> Clive McCarthy writes:
>>> ... The import libraries for both of these DLLs are also in Microsoft
>>>format but it has been easy to convert these to Borland format using a
>>>simple tool that is part of the Borland software suite.
>>
>> MinGW uses same the PE-COFF library format as Microsoft, so you should
>> just able to the import libraries as is without conversion. It doesn't
>> support the OMF format used by Borland. MinGW can also use the DLL
>> itself as if it were an import libray, so there's no need to play around
>> with dlltool.
>>
>> Ross Ridge
>
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_facebook:082009
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Matthew Talbert
> Does anyone have a nice MinGW libfreeglut.DLL and libfreeglutwin.a ?

I apologize if this has already been mentioned on this thread, but you
do know that you can link to a dll directly? That is, just specify
/path/to/some/dll.dll on your link line and it will be linked in. No
messing around with .def, .a, .la, .dll.a, etc.

Matthew

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: MinGW existing DLL linking

Clive McCarthy

Matthew,
Yes somebody did tell me that as long as the DLL was built with Microsoft tools that the DLL can be used directly by the gcc linker without an import library. I wonder if this is true for those DLLs that have __stdcall interfaces or just those with __cdecl interfaces (or vice versa)?

The Nate Robins glut DLL has the __stdcall interface but the DLL has the @ calling decorations removed, which is I gather quite common -- that is why I couldn't link to the import library I extracted from it. My libtiff3 and libjpeg62 DLLs both use the __cdecl interfaces so that is why they worked.
 
The good news is that, on a whim, I tried the freeglut DLL that I "found" and that DLL uses __stdcall (just like glut) but it _does_ have the @ decorations -- so it works right out of the box.

Clive.

>
>> Does anyone have a nice MinGW libfreeglut.DLL and libfreeglutwin.a ?
>
> I apologize if this has already been mentioned on this thread, but you
> do know that you can link to a dll directly? That is, just specify
> /path/to/some/dll.dll on your link line and it will be linked in. No
> messing around with .def, .a, .la, .dll.a, etc.
>
> Matthew
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users