[Wine] Can I use a static build to install on an obsolete target?

[Paul Jackson]

Alexandre Julliard wrote:
> Alan McKinnon <alan.mckinnon at gmail.com> writes:
> 
>> Fair enough. It's an interesting answer, so what's the reason that wine 
>> can't be built statically? A design decision or a technical (code) 
>> reason somewhere?
> 
> Technical reasons. Windows can't be built statically either, dynamic
> loading is very much integral to the whole design. Wine is not a
> stand-alone application, it's really a set of libraries, the true
> application is the Windows binary, so that's what would have to be
> statically linked.
> 

On the other hand, if "wine" could be built as a single (or even lots 
of) so/dll(s) which statically incorporated all the required Unix code, 
then Dependency Hell would be history. The Windows binary then 
dynamically links to a single (or multiple) lib/s which can be carried 
to more-or-less-any Linux/whatever platform. Or is that far too simplistic?

Or, to put it another way: the dependency problem exists because a 
dynamically linked app dlopens libs which may potentially not exist on 
the target, and which could be very difficult to build on the target. So 
why not just statically incorporate the Unix code? No dependencies, and 
the windows world can't tell.

I've moved on to plan D, which is to dump wine (sorry... :() and use RPC 
  to communicate with a Windows box (and another Linux box which does 
run Wine). Still, I would really have liked to see this work.

- Paul