On Sat, Jun 23, 2007 at 12:03:47AM +0200, Volker Grabsch wrote: > On Fri, Jun 22, 2007 at 08:50:14PM +0930, Ron wrote: > > You should be able to do away with the dll.a file now, mingw has > > been able to link directly to the .dll without an explicit import > > lib for some time now... > > We know this, but libtool doesn't. So you either leave the *.dll.a > in you package, or you have yet another thing to patch in all packages > that depend on that lib.
Ahh. Yet another reason I'll never use or recommend libtool. ;-) I really like autoconf, but some of the helpers built on top of it leave a lot to be desired in the real world. > > that can help a little, making *.so > > and *.dll more similar in the way they are used in build scripts. > > Unless you rename the *.dll files into *.so, you'll have to patch the > "*.files" anyway, thus having no chance to convince the package > maintainers. Yeah, and then that will cause its own problems with other things too. I guess the fundamental problem is that we are pushing the bounds of 'traditional' portability. Instead of just being portable between POSIX variants this adds several dimensions of additional incompatibility that need to be mapped somehow. On some level I think that's going to be intractable to deal with unless upstream authors are directly engaged (or their work forked) to handle systems they don't already support. With proper upstream support, the level of patching required for packaging should usually be minimal. Without it, not only the packaging, but the source itself may need to be patched. If not now, then perhaps with some later release. OTOH, I suspect it is only a matter of time now before we see full POSIX support in future MS operating systems. I'm personally growing in the opinion that until then, users of that system are best and most painlessly served by treating it as a dumb terminal that gives them a web browser interface to things running on a Real OS. That wasn't a practical solution when I first got serious about cross platform application development, but currently it seems to be maturing as a viable solution faster than some of the other options. That still doesn't work for everyone, or everything yet, but its been quite a while since it hasn't Worked For Me with my real life needs, and I suspect I'm far from alone in that. As the user demographics shake out on a scale that might look something like: Win32 -> MacOS -> Lindows -> Ubuntu -> Debian, this certainly seems like an appealing solution for developers of EMDebian platforms that want to support all of these with their products. Things like Google's office suite are certainly going to add to the measure of whether there really is much of a future for 'native' win32 apps. It's going to be interesting to see how the balance of these approaches evolves over time. Especially if rather than going down the POSIX road MS really do continue to make their browser an inseparable primary interface to everything the user does on the machine. Even if all some people use it for is to launch a 3rd party secure renderer of http streams ;-) Anyway, that's just my musing on why win32 ports might not be gaining the sort of mindshare I'd have though they might by this time, and how the ground might change from under them if they don't gather speed soon. I'd still like to see more code more friendly to cross builds, since the disparity between development platforms and user platforms is sure to continue to increase. The win32 platform is a good acid test for that, since broken assumptions very quickly lead to broken portability ;) Even if we don't need it now, there are clues in what you learn that can improve the way we do things... Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
