This is a quite confusing post (to me). My confusion comes from phrases like "In a C environment" and "in a (MinGW-built) Perl environment".

I assume that by the former, you mean using 'the linker' from either directly from the command line, or indirectly via a command in a makefile.

And in the latter, using 'the linker' indirectly through a command line generated via EU::MM (or an EU::MM generated makefile.pl).

And later in the post you say "OTOH, the MSVC compiler is quite capable of linking to '.a' and '.dll.a' libraries (but not directly to dll's)". This is confusing because you don't link to .lib/.a files. You can link via a .lib/.a to a .dll.

Some MS nomenclature with *nix equivalencies (as best I know them; and sorry that most of this will be old info to you, but its the bits that aren't where either you are getting confused, or I am :):

• link.exe/ln aka. 'the linker'

  This takes a one or more .obj/.o ('object') files, and/or one or more .lib/.a ('library'/'archive') files and extracts what it needs and cobines them to produce an executable file.

• .lib/.a files:

  These are non-executable collections of 'object files'. These are a substitute for supplying the path/names of all of the require 'object' files to the linker on the command line.

  Also a convenient way of distributing a collection of 'object' files.

  A .lib can also be an 'import library'. This doesn't contain onject files as with a normal .lib, but rather is basically an index to a .dll.

  The suffix .dll.a (which would be .dll.lib in MS-speak) has no direct equivalent in MS-land. They are both .lib. Which makes a certain amount of sense as they both serve a similar purpose. They either supply the object code for entry points; or they supply the name of a .dll which contians that entry point for dynamic linking.

• .dll/.so ('dynamic link') files.

  These are "executable" files. Not runnable directly, but still executable.

  The 'linker' builds these. It does not use them directly.

  In order to build an executable (.exe or .dll), that is statically linked to a .dll, you need a import library. This can be generated by the 'linker' when building a .dll. Or it can be generated from a .dll later using implib.exe ('import library utility'), if you have it.

All of which is leading up to this. I'm not sure whether the "search order" you describe for the MinGW linker is implemented by the linker itself? If it is, there is no equivalent for that using link.exe.

About the best that could be done to resolve the problem you are seeking to address, would be for the EU::MM to generate code in the makefile.pl it creates to cause it to go looking for each of the various suffixes when generating the makefile, and hardcode which ever it finds into the makefile.

link.exe doesn't care what the suffix on object libraries or import libraries is. It simply opens the named files and examines the contents to see if it recognises it and how to use it.

I'm not sure how helpful any of that is?