Hi ALL, I've made WineLib applicatiion with COM support. The first problem is: when I try to call Release() method for interfaces, I have unhandled exception. But I have to clean memory by myself! It seems to me that WineLib Releases all interfaces before me. The second problem: How can I package my application to install it on another computer? Can I avoid Wine installation on that computer? Thanks, Oleg Lyamtsev.
The second problem: How can I package my application to install it on another computer? Can I avoid Wine installation on that computer?
AFAIK at the moment yes, you need to either install Wine or basically ship your own version with the application. You can probably use RPM/DEB for that at the moment, hopefully something better will come along in the next year or so
Thanks, Oleg Lyamtsev.
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Mike Hearn wrote:
The second problem: How can I package my application to install it on another computer? Can I avoid Wine installation on that computer?
AFAIK at the moment yes, you need to either install Wine or basically ship your own version with the application. You can probably use RPM/DEB for that at the moment, hopefully something better will come along in the next year or so
I should point out that Mike is working on something meant to replace RPM and DEB packages, which is why he delivered that glancing insult at them :-) There's also the LSB package, which solves all dependency problems by requiring the package to be linked statically with anything it needs that's not defined by the LSB. I rather like this, but Mike hates it. Now that distributions are becoming LSB-compliant, it's time for people to consider packaging their apps as LSB packages, I think. When and if Mike's effort becomes "Son-of-LSB-package", it will just reduce the bloat associated with static linking, I think. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
I should point out that Mike is working on something meant to replace RPM and DEB packages, which is why he delivered that glancing insult at them :-)
lol, well our stuff won't be ready for a while yet, and I didn't mean for it to be an insult. As it says on the FAQ on our site, we're not intending to replace RPM or DEB, far from it. Anyway, there's not much intrinsically wrong with RPM or DEB themselves, the main problem is that you have to make them for each distro, although source rpms can be fairly neutral (ignoring dependancy naming etc) you still have to tweak them for particular distros usually, which is rather sucky. That's more a Linux-wide problem though rather than an issue with those particular packaging systems.
There's also the LSB package, which solves all dependency problems by requiring the package to be linked statically with anything it needs that's not defined by the LSB. I rather like this, but Mike hates it.
It's interesting, I was just talking to Doug Beattie about this very issue, he picked up on a mail I sent to the CrossOver list and suggested maybe Wine could become LSB compliant. That's certainly a good long term goal (and i've considered working on it myself) but yeah, statically linking everything is a super-ugly solution :( Maybe it'd work OK for Wine, I'm not entirely sure how many dependancies it has, but I'm not sure it's many more than what the LSB standardises. Given the current threading problems, I kind of suspect the LSB can only solve some of the problems related to portability of Wine on Linux.
Now that distributions are becoming LSB-compliant, it's time for people to consider packaging their apps as LSB packages, I think. When and if Mike's effort becomes "Son-of-LSB-package", it will just reduce the bloat associated with static linking, I think.
There are a whole load of issues that need to be addressed really, the static linking thing is only one of them. At some point this week I'm going to try and get the new packaging group underway, focussed at first simply on improving the LSB RPM system so it can have dependancies. Anyway, that's a bit OT. It'd be good to have an LSB package of Wine available, that'd certainly ease the burden of packaging. You'd still need at least two for the different glibc versions though, I don't think there's any way around that until the transition to the new glibc is over :( Maybe Alexandre can work some magic so that one binary of Wine can deal with both, that'd be pretty good, but I think the answer is it'd be a compile-time thing. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
participants (3)
-
Dan Kegel -
Mike Hearn -
Oleg Lyamtsev