don't ask me to explain this idiocy

Oh, come on. Since this problem will probably affect other people too, it could be helpfull.

Um, I can't explain, why the maintainers of ExtUtils::Liblist, "improved" their module, by necessitating :nosearch to get the old default behaviour

I can't even remember why/when it changed, just that old way of people did things, you might get a dozen

Note (probably harmless): No library found for -ltcl86
Note (probably harmless): No library found for -lmoldname 
Note (probably harmless): No library found for -lkernel32
[download]

messages, but each and every -ltcl86 still got forwarded to the compiler/linker, and if the compiler/linker couldn't find -ltcl86 and it was really needed, then it would throw an error, and you'd know which one of the harmless warnings weren't harmless after all

For example, mingw gcc, when you tell it -ltcl86, knows to check for a whole bunch of variations tcl86.lib, tcl86.a, tcl86.la, tcl86.o, libtcl86.lib, libtcl86.a, libtcl86.la, libtcl86.o... because it knows how to handle all these (both .a and .lib)

But, MakeMaker/Liblist, after decades of letting the compiler/linker handle it as usual, finally tries to do its intended job (i guess), but it only consults

$ perl -V:lib_ext
lib_ext='.a';
[download]

Which doesn't quite work for windows/mingw/gcc combination

note: I'm aware some of the details above aren't 100% accurate, but the general gist is, liblist removes libs the compiler knows how to handle, :nosearch restores the old default