Just rename latest and it works, bug suffers from same issue as the 2.x->3.x upgrade, see bug#486832. Include files of sysroot are injected before these in libc, causing build to fail. Workaround is to clean/build. I reported this once again to upstream, I hope they will address this issue. Please tell me if you want to add it anyway.
Created attachment 399354 [details, diff] mingw64-runtime-4.0.0.ebuild.diff They solved it in 4.0, for some extent. Please review.
what is with all the multilib logic ? we don't support multilib installs with cross-xxx packages.
(In reply to SpanKY from comment #2) > what is with all the multilib logic ? we don't support multilib installs > with cross-xxx packages. it is multibuild not multilib :) I used this eclass to build the header in separate builddir, I can do this manually instead if you think this eclass is not helpful.
(In reply to Alon Bar-Lev from comment #3) any time i see use of "copy sources" funcs, i look for a different route i'm not seeing why you need it here at all though
(In reply to SpanKY from comment #4) > (In reply to Alon Bar-Lev from comment #3) > > any time i see use of "copy sources" funcs, i look for a different route > > i'm not seeing why you need it here at all though if we build the library what we actually need to do is: 1. build and install the headers into temporary location. 2. build the library with header of (1). this enables upgrade sequence to actually work, as the library use the sysroot include by default. so I used the multibuild eclass to copy the sources into alternate location, and configure/build at that location to deploy the header in temporary location. this way the src_configure can configure the two sources with different settings, while the src_compile to build.
4.0.1 is out, same build.
Hi vapier, Can we add it, or you want me to get rid of the multi-build eclass usage?
Created attachment 402652 [details, diff] mingw64-runtime-4.0.1.ebuild.diff
Created attachment 402654 [details, diff] mingw64-runtime-4.0.1-winpthreads.patch
Created attachment 402656 [details, diff] mingw64-runtime-4.0.1-build.patch
sorry, i'm still not groking the need for the multibuild stuff. if we did the bump w/out that, i'd certainly LGTM it quickly ;). the winpthreads patches look fine (assuming you're shepherding them upstream since you're good about that).
Created attachment 402676 [details, diff] mingw64-runtime-4.0.1-build.patch
Created attachment 402678 [details, diff] mingw64-runtime-4.0.1-winpthreads.patch
Created attachment 402680 [details, diff] mingw64-runtime-4.0.1.ebuild.multi.diff
Created attachment 402682 [details, diff] mingw64-runtime-4.0.1.ebuild.multi.diff multi build version
Created attachment 402684 [details, diff] mingw64-runtime-4.0.1.ebuild.diff None multi build version
(In reply to SpanKY from comment #11) > sorry, i'm still not groking the need for the multibuild stuff. if we did > the bump w/out that, i'd certainly LGTM it quickly ;). I've attached both versions with multi-build and without. > the winpthreads patches look fine (assuming you're shepherding them upstream > since you're good about that). sure, already sent, will work to merge this functionality one way or the other.
Comment on attachment 402684 [details, diff] mingw64-runtime-4.0.1.ebuild.diff >+MULTIBUILD_VARIANTS=( headers ) left over ? :) >+crt_with() { >+ just_headers && echo --without-$1 || echo --with-$1 >+} >+crt_use_enable() { >+ just_headers && echo --without-$2 || use_enable $* >+} >+crt_use_with() { >+ just_headers && echo --without-$2 || use_with $* >+} use "$@" instead of $* >+ if ! just_headers; then >+ mkdir "${T}/headers" >+ pushd "${T}/headers" use $WORKDIR instead of $T send pushd/popd output to >/dev/null >+ $(crt_use_with libraries libraries winpthreads,libmangle) \ should we even make this an option ? or just always enable them ?
Created attachment 402686 [details, diff] mingw64-runtime-4.0.1.ebuild.diff
(In reply to SpanKY from comment #18) > >+ $(crt_use_with libraries libraries winpthreads,libmangle) \ > > should we even make this an option ? or just always enable them ? I thought of avoiding issues in most configurations by compiling less. But real reason is that at phase1 gcc I am unsure we will be able to build all libraries, so we can disable this at bootstrap then enable and rebuild.
Created attachment 402702 [details, diff] mingw64-runtime-4.0.1.ebuild.diff sorry, forgot the $@, it should be ok now.
(In reply to Alon Bar-Lev from comment #21) looks ok ... lets start here and iterate on top (i.e. feel free to commit)
OK, thanks.
