Re: [Mingw-users] lesson: don't have a dll and a lib in the same library path
- Date: Thu, 20 Dec 2007 21:07:38 -0800
- From: Brandon Sneed <brandon@xxxxxxx>
- Subject: Re: [Mingw-users] lesson: don't have a dll and a lib in the same library path
On Dec 20, 2007, at 5:58 PM, Greg Chicares wrote:
> On 2007-12-20 22:17Z, Brandon Sneed wrote:
>> This is just to document this in case anyone else runs into it...
>>
>> I had to make a library (.a) from a vendor DLL. I copied the DLL
>> to a
>> temp directory, created a def for it in the same directory and used
>> dlltool to create a library from said DLL. i think tried to compile
>> and link with that library and LD generated errors for every function
>> in the DLL basically saying it couldn't find _SomeFunc@n x300 or so
>> imports.
>>
>> After 4 days of fighting with it, searching google (maybe with the
>> wrong search terms) etc. on a lark, i deleted the DLL and wala, it
>> all
>> linked fine.
>>
>> So.. if this is you (person reading the archives), delete that DLL!!!
>
> What exactly were the dll and the import library named?
> AIUI, using a '.dll.a' suffix would give precedence to the
> import library, so you wouldn't need to delete the dll.
> See the link below.
the dll was "utpapi.dll" and the library was "libutpapi.a".
>
>
>> I had previously thought that while linking to DLL's was possible, it
>> required command line parameters other than "-l<library>".
>
> http://sourceware.org/binutils/docs-2.18/ld/WIN32.html#index-direct-linking-to-a-dll-610
thanks for the link. I may have actually spoken too soon. when i got
around to actually running the built app, windows complains that
"CloseController@4" was not found in UTPAPI.DLL. so while that one
issue was fixed, i have another to deal with i suppose.
the DLL exported it as just "CloseController". My def file has
"CloseController@4" in it. I also tried several permutations of
"CloseController=CloseController@4" and a few other combos which all
either wouldn't link, or wouldn't run. The functions are defined in
the header as __stdcall which seems to be at the root of things.
Surely there is some easy way around this. I could've swore i had
done this with other dll's many times before, but i'm just drawing a
blank. most likely because of frustration :(
Brandon Sneed
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users