finding libraries in sys_lib_search_path

[Markus Duft]

Hey all!

i'm on interix, and have the following issue when linking libpng:

/tools/mduft/gentoo-itxf/bin/bash ./libtool --tag=CC   --mode=link
i586-pc-interix5.2-gcc   -rpath '/tools/mduft/gentoo-itxf/usr/lib'
-no-undefined -export-dynamic -version-number 3:40:0  -o libpng.la
libpng_la-png.lo libpng_la-pngset.lo libpng_la-pngget.lo
libpng_la-pngrutil.lo libpng_la-pngtrans.lo libpng_la-pngwutil.lo
libpng_la-pngread.lo libpng_la-pngrio.lo libpng_la-pngwio.lo
libpng_la-pngwrite.lo libpng_la-pngrtran.lo libpng_la-pngwtran.lo
libpng_la-pngmem.lo libpng_la-pngerror.lo libpng_la-pngpread.lo  -lz -lm

*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz but no candidates were found. (...for regex pattern test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

of course, the file is there, but obviously in a path that is not know
to libtool (in libtool's $prefix/lib) ... (?!?)

gcc here is a wrapper that adds another bunch of paths to the command
line, which do
n't appear in -print-search-dirs ... :(

manual patching of sys_lib_search_path_spec to include the required dirs
did the trick, but somehow this feels too hacky.

Cheers, Markus