Re: compat32-* packages for Wine

[zerous <zerous@nocebo.space>]

On Sat, Jul 13, 2019 at 08:19:55AM -0400, Greg Troxel wrote:
> zerous <zerous@nocebo.space> writes:
> 
> > On Fri, Jul 12, 2019 at 07:26:35PM -0400, Greg Troxel wrote:
> >> I would like to take a step back and look at the bigger picture of what
> >> you are doing.  This seems hugely useful, but I'm not sure which way is
> >> up.
> >> 
> >> You are talking about packages "which crosscompile programs for i386 on
> >> amd64".  I would like to understand how that differs from
> >> "crosscompiling a program for i386" separately from host architecture,
> >> and if this is just a specific case of using generic crossbuild
> >> infrastructure.
> >
> > I think crosscompiling a program for i386 separately from host
> > architecture is the most generic way of looking at it. And yes,
> > crosscompiling a program for i386 on amd64 is just a specific use-case
> > that I focussed on owing to porting Wine to amd64.
> 
> We have a way to do cross compiling.  You seem not to be using it, and
> reimplementing it somehow.  That is what I am trying to get at.

Yes, I know that I haven't been following the convention. The
rationale is that I won't be able to finish porting wine to amd64
within GSoC time-frame if I follow the generic approach.

> 
> >> I wonder if the packages that are created are in fact the same as the
> >> package that would be built on i386, modulo timestamps and other things
> >> people worry about during reproducible builds.   And if not, why not.
> >
> > I don't know about this issue and I haven't come across it yet. I
> > shall keep an eye out though.
> 
> I would suggest that you actively check.
> 
> >> I wonder if the wine you are building will be a 32-bit wine binary that
> >> runs under netbsd32 emulation, and how that's different from the wine
> >> built on i386.  I get it that you will have to make the netbsd32
> >> emulation do a lot of complicated stuff that probably does not work now.
> >> But I wonder how much of the 32-bit cross is about making wine work on
> >> amd64, vs making it easy to build.
> >>
> >
> > I am not trying to crosscompile wine 32-bit so that I can run it using
> > compat_netbsd32. I have been trying to do a Wine WoW64 build which
> > requires crosscompiling wine 32-bit, and using the latter to inject 32
> > bit Wine libs, and whatever glue is required to make Wine 64-bit run
> > 32-bit Windows applications on amd64.
> 
> I am not following.  Can you explain the big picture?  Is "64 bit wine"
> about running windows programs compiled for an x86-64 processor on a
> NetBSD/amd64 system?  Does this work, for native 64-bit programs,
> without needing any i386 libs?  Is this entire exercise then about
> supporting windows32 programs on NetBSD amd64?
> 
> And, if you just build the packages on netbsd/i386 system, and use the
> libs from those, does that work?  I am trying to understand if the cross
> compiling exercise is know to be sufficient and you have already made it
> work by hand, or if there's something else going on.
> 
> If this is on some wiki or web page, that's even better and feel free to
> tell me to go read it.
> 

64-bit Wine is only capable of running 64-bit Windows applications. However,
the majority of Windows Applications are 32-bit (at least most installers are)
which is why we need to have Wine 64-bit with WoW64 support as it is capable
of handling both 32-bit and 64-bit Windows applications.

You can read about this here:
https://wiki.winehq.org/Building_Wine#Shared_WoW64


> > Not at all :)
> > I was just trying to get Wine WoW64 build to work as soon as possible,
> > and was hoping to find the right approach of doing things in the
> > process. I shall have a look at how we are handling linux packages and
> > try to adapt it for 32 bit packages.
> 
> There are two parts: installing a foreign OS package, which we do for
> Linux, and crossbuilding.  pkgsrc crossbuilding support is a little
> rocky but the docs were improved in the last week or so.
> See /usr/pkgsrc/mk/HOWTO-*-crosscompile.
>

I shall go through the guide and will try to follow it when updating
existing packages. But, I am afraid I will only be able to do this
after GSoC due to time constraints.

> I think it would be a far greater contribution to have a way to
> cross-build  the packages you need via a generic approach, then to add a
> dozen special-case packages to the tree.  I also think it will end up
> being easier.
>

I totally agree with you on this.

-- 
zer