Re: d3dx9.lib is not managed by ld, but libd3dx9.a is

[Ralf Wildenhues]

* Roumen Petrov wrote on Thu, Jun 04, 2009 at 08:54:24PM CEST:
> Vincent Torri wrote:
>> I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass  
>> -ld3dx9 and i have added everything so that the dll is built.
>>
>> If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual 
>> warning message from linker / libtool:
>>
>> *** Warning: linker path does not have real file for library -ld3dx9.  
>> blah blah blah
>>
>> and only the static lib is built.
>>
>> If I rename d3dx9.lib to libd3dx9.a, then the DLL is built. I don't  
>> understand why because, according to the doc of ld for win32:
>>
>> http://sourceware.org/binutils/docs/ld/WIN32.html
>>
>> if I pass -ld3dx9, then d3dx9.lib should be used.
>>
>> What is the reason of the failure ?

libtool does not currently look for FOO.lib only for libFOO*

> I'm not sure that libtool has to deal with library '.lib' suffix.

Maybe not with library creation (well, that's another question at this
point at least), but it should find such libraries on this system I
think.

> From  
> the suffix is not clear type of library file - static or import library.

That's what func_win32_libid ought to check.

> GNU compiler(mingw) use suffix '.a'  for static library and '.dll.a' for  
> import libraries.
> If a xx.lib file is found in search path libtool has to process file and  
> to find its type(static/import). This impact performance.

Well, yes.  The expensive part should only happen when we already have a
candidate library, however, so it should not happen too often.  And
correctness trumps performance.

Is this perchance fixed already in the pr-msvc-support branch?

> Also support for MSVC import libraries isn't perfect and linker will  
> fail to link if a library export variables. Note in this case GNU linker  
> succeed to link directly shared(DLL) library.

I'm not quite sure what this is hinting at.  A bug in the MSVC linker?
Well, that would just reinforce the point that variables should not be
part of library exports.

Thanks,
Ralf