When cross-compiling the library with mingw32, the generated DLL import library uses a non-standard name (libzdll.a), which is not automatically recognized by mingw32-ld. Subsequently building packages that link against -lz fail to find it. Of course, I could be missing something else...is no one using this since bug 182903 (initial mingw cross support)? To reproduce, you need the amazing magic of mingw crossdev and wrappers setup, then just emerge anything that depends on zlib: # mingw32-emerge sys-libs/zlib media-libs/libpng zlib emerges fine, but during the linking of libpng I see several warnings from libtool as it decides to skip building the libpng DLL: *** Warning: linker path does not have real file for library -lz. ...blah blah blah... *** libtool will only create a static version of it. Note that the ebuild still appears to succeed, even though it is incomplete (no DLLs produced). Similarly for other packages I tried that link to -lz Attaching a patch that fixes things...
Created attachment 206446 [details, diff] zlib-1.2.3-mingw-implib.patch Adjust the name of the mingw import library consistent with the default ld/libtool search.
Created attachment 206447 [details] zlib-1.2.3-r1.ebuild Adjust the name of the import library consistent with the default ld/libtool search. I also moved the DLL under bin, where it can be found at runtime (consistent with other packages built in the mingw cross environment).
i really dont know much about creating shared libraries with mingw, so i'm hesitant to add anything that can change the ABI of the dll. such compatibilities are a nightmare for windows users.
well, i certainly understand that hesitancy :) i believe that the ABI of the DLL is unaffected by the name of the import library. as i understand it, this import library is just a static library that stubs out each of the interfaces and manually accomplishes what ld.so does for us automatically in *nix with eg, _dl_runtime_resolve. by changing the name we only make it easier for ld to find this stub at link time under an expected name - there is no functional impact on either the DLL generated by this package or other binaries linked against it. i made an attempt to prove this out; attaching a diff showing that the DLL generated by the stock ebuild and the DLL generated by the proposed change differ only in their timestamp
Created attachment 206594 [details, diff] zlib1.diff (golden vs proposed) diff showing that the mingw32 cross DLL produced by the current zlib-1.2.3-r1 differs from the proposal only in timestamp, indicating the ABI is unchanged. generated with these commands: # PORTDIR_OVERLAY= mingw32-emerge zlib # ls -l /usr/mingw32/usr/lib/zlib1.dll -rw-r--r-- 1 root root 78465 Oct 9 18:51 /usr/mingw32/usr/lib/zlib1.dll # mingw32-objdump -xs /usr/mingw32/usr/lib/zlib1.dll > zlib1-golden.dump # PORTDIR_OVERLAY='/usr/mingw32/usr/portage' mingw32-emerge zlib # ls -l /usr/mingw32/usr/bin/zlib1.dll -rwxr-xr-x 1 root root 78465 Oct 9 18:52 /usr/mingw32/usr/bin/zlib1.dll # mingw32-objdump -xs /usr/mingw32/usr/bin/zlib1.dll > zlib1-proposed.dump # diff zlib1-golden.dump zlib1-proposed.dump > zlib1.diff
ok, that works for me. thanks for the due diligence. in the future, changes to ebuilds should be posted as diffs so people can quickly review what has changed rather than fetching the new ebuild and doing the diff themselves changes should be in cvs now: http://sources.gentoo.org/sys-libs/zlib/zlib-1.2.3-r1.ebuild?r1=1.13&r2=1.14 http://sources.gentoo.org/sys-libs/zlib/files/zlib-1.2.3-mingw-implib.patch?rev=1.1
