[Wine] Can I use a static build to install on an obsolete target?
sa212+wine at cyconix.com
Thu Jan 3 13:33:07 CST 2008
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.
More information about the wine-users