So I've been experimenting with virtuals and dependency resolution with portage, and I think the best way we could handle crossdev's mingw-w64 toolchain is to create a new virtual/mingw ebuild, which has no deps of its own, and have a few of our existing virtuals depend on it. So far virtual/opengl and virtual/glu are good candidates for it. The reason this is required is cross-$CTARGET/mingw64-runtime installs to /, but includes the headers and files needed to build opengl/glu based programs (such as media-libs/libsdl2[opengl]), but cross-$CTARGET/mingw64-runtime is invisible to $CTARGET-emerge. /usr/$CTARGET/lib/libglaux.a /usr/$CTARGET/lib/libglu32.a /usr/$CTARGET/lib/libglut.a /usr/$CTARGET/lib/libglut32.a /usr/$CTARGET/lib/libopengl32.a /usr/$CTARGET/usr/include/GL /usr/$CTARGET/usr/include/GL/gl.h /usr/$CTARGET/usr/include/GL/glaux.h /usr/$CTARGET/usr/include/GL/glcorearb.h /usr/$CTARGET/usr/include/GL/glext.h /usr/$CTARGET/usr/include/GL/glu.h /usr/$CTARGET/usr/include/GL/glxext.h /usr/$CTARGET/usr/include/GL/wglext.h Maybe also add it to virtual/libc, but unsure of how needed that is, as I don't find much that depends explicitly on virtual/libc in the portage tree.
I've started work on this virtual and a proper windows/mingw profile for use with crossdev, you can see my current progress on my github repo[1] [1]: https://github.com/hanetzer/gentoo/tree/mingw-profile
As just discussed on IRC: I close here, because this ticket needs some more discussion and the bug tracker is not well suited for discussion. As soon as the ticket is beyond the brainstorming stage, we can reopen it, or you create a new one for better readability.
