Alexandre Julliard wrote: > Alan McKinnon <alan.mckinnon@xxxxxxxxx> 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 _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
