Breakage can be prevented by setting STRIP=true and by only calling ``emake install'' if the CHOST isn't mingw32. I'll attach a patch that gives me working mingw32 support.
Created attachment 224305 [details, diff] zlib-1.2.4.ebuild-mingw32-pkgconfig.patch Fixes cross-compiling for mingw32, including some fixes I mentioned above. Also provides pkgconfig support for mingw32 target. Also adds multilib to the list of inherited classes because it is used by non-mingw32 code and it is assumed that toolchain-funcs will inherit multilib for the ebuild (IMO, it's best to systematically avoid this assumption as much as possible). If anybody has any direction or knowledge of ways to support w32 crosscompiling (I'm thinking a profile and maybe ARCH=w32, KEYWORDS=~w32), I'd be interested in being directed there :-)
Created attachment 228553 [details, diff] zlib-1.2.5.ebuild.diff mingw fixups. I don't truly understand why mingw-implib.patch is needed. And why we need pkg-config file, what/who uses it in mingw environment?
pkg-config doesnt care about the target. it'd work fine in any cross-compiling environment.
(In reply to comment #3) > pkg-config doesnt care about the target. it'd work fine in any cross-compiling > environment. But pkg-config must have wrapper or something, and libtool does not use it anyway... Is it actually required for something? If we start making mingw cross compile for packages, there is a lot of work out there...
libtool and pkg-config have nothing to do with each other. you dont need a wrapper for pkg-config any more than you need a wrapper for any other target -- a wrapper simply automates the library lookup process when cross-compiling. the only reason there is mingw logic in the zlib ebuild is because its build system sucks and has dedicated makefiles for certain targets. that is all. this is no different from adding bsd handling when a package has dedicated bsd build files. really the zlib build system should be shot and moved to autotools so that things "just work" for mingw targets.
I tried to discuss the autotools stuff when I sent latest cross and mingw patches to zlib. This was rejected as they support cmake now. Tried to tell them that core component like zlib should have minimum dependencies, and that they have circular dependency (cmake requires zlib), but they all reject autotools. For pkg-config, you know better than I... if prefix is /usr then you have issues with cross compile ROOT is different, need wrapper to fix this in most cases. Anyway, it is missing only in mingw no problem to add it if something actually requires it.
if the stock zlib installs a .pc, then it should for all targets the pkg-config wrapper isnt to mung the output, it's to quickly set up the relevant env vars. pkg-config itself has support for sysroots and will change standard -I/usr/... and -I/usr/... paths to look in the specified sysroot.
Created attachment 228555 [details, diff] zlib-1.2.5.ebuild.diff OK. Had I know this I would have pushed this too into 1.2.5.
Created attachment 228559 [details] zlib-1.2.5.ebuild.diff Sorry, leave the implib patch. I will try to push this too.
Created attachment 228565 [details, diff] zlib-1.2.5.ebuild.diff So sorry! They added a new sharedlibdir in last version, so the pc creation is updated.
> the only reason there is mingw logic in the zlib ebuild is because its build > system sucks and has dedicated makefiles for certain targets. that is all. Did you already try ./configure && make on mingw ? (didnt have time to check it yet) Perhaps we should fix from the start. The changes could be made in the oss-qm branch, until Mark has catched up w/ next release: http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.zlib.master > really the zlib build system should be shot and moved to > autotools so that things "just work" for mingw targets. No, we definitivly dont want autotools, because it does _NOT_ work properly. (see the discussions frequently popping up again @zlib-devel). If you have something to fix, please come up w/ a patch or at least enough information for us to fix it.
(In reply to comment #6) > I tried to discuss the autotools stuff when I sent latest cross and mingw > patches to zlib. This was rejected as they support cmake now. Tried to tell > them that core component like zlib should have minimum dependencies, and that > they have circular dependency (cmake requires zlib), > but they all reject autotools. cmake is not needed at all for zlib. The cmake buildfile is as optional as the treebuild.xml. autotools would conflict w/ the current carefully handwritten configure script and introduce a hell of other problems. > For pkg-config, you know better than I... if prefix is /usr then you have > issues with cross compile ROOT is different, need wrapper to fix this in most > cases. Thats not necessary anymore, for several years now. Just pass the right PKG_CONFIG_SYSROOT_DIR env variable.
(In reply to comment #3) > pkg-config doesnt care about the target. it'd work fine in any cross-compiling > environment. > Actually, pkg-config is *very* useful for crosscompiling.
i really have no idea what Enrico is talking about, so i'll skip that i dont like extending the mingw cruft so much, but since i'm not inclined to dig into the zlib source for a proper fix, i've merged Alon's latest patch http://sources.gentoo.org/sys-libs/zlib/zlib-1.2.5-r2.ebuild?r1=1.3&r2=1.4
(In reply to comment #14) > i really have no idea what Enrico is talking about, so i'll skip that > > i dont like extending the mingw cruft so much, but since i'm not inclined to > dig into the zlib source for a proper fix, i've merged Alon's latest patch > > http://sources.gentoo.org/sys-libs/zlib/zlib-1.2.5-r2.ebuild?r1=1.3&r2=1.4 > My primary point is fixing the configure script, so it supports mingw builds, instead of driving the buiild manually.
