Hi Brandon, thanks a lot for your reply. The reason I link the library statically is because my client wants what he calls "a single product". He didn't want two prc's because the product will be used for people with none or very few knowledge of technology (I still don't understad how 2 instead of a single prc make any diference). I found a product called nutshell that creates a prc installer for two or more prc and pdbs. He didn't like it neither. He said: "I want a professional solution". But linking statically is not a professional solution, it seems more like a patched app whose code increases by 30-40% just for doing a single task: compression. Actually I don't like this idea, I agree with you, it's just I was asked to do this way. And because I've been a palm developer for very few time (3-4 months) I didn't know how to include zlib as a resource (I keep learning and learning...). I like this approach (it's like nutshell's, isn't it?) If you could shed some light, how can I create the shared library from the resource? I mean, I don't expect you to give me step by step what to do exactly, but maybe some links to docs, examples, etc. I'm using prc-tools and pilrc.
Thank you very much for your reply,and as you can see and might expect, it seems there's no valid reason to statically linking a library like zlib, at least, not for me, neither. Miguel
Brandon Roberson wrote:
Out of curiousity... If you've linked zlib statically with your app, and so have I, and so have thirteen other people on this mailing list, all because none of us want to distribute a separate PRC with our apps... isn't that a little counterproductive? If I were running all those apps, and I wanted to use the latest version of SysZLib.prc that gave a 200% performance boost because of a particular nifty feature of my handheld... it wouldn't effect any of those apps because they've statically linked various older versions of ZLib.
Wouldn't it be better to include your preferred version of ZLib as a resource? Then its a matter of: Open the shared library. Can't? Load the shared library. Can't? Create the shared library from the resource, rinse, and repeat.
It'd result in the nearly the same PRC size (arguably a waste of space, but you really don't want to distribute a separate PRC for some reason), but if your preferred version of ZLib happens to make my brand new Tungsten T|7 with holographic non-volitile pseudomemory go haywire, at least I can put a version of ZLib on there that works and your app can use it. Otherwise, I don't get to be your customer.
Basically, shared libraries are a Good Thing (tm) and statically linking them, although tempting, really doesn't make things as tidy as you might think.
Oh - and this isn't preaching, though it might sound like it. Its just the result of alot of thought, and the eventual decision to *not* do exactly what you're doing. I'm really interested in hearing reasons why I'm mistaken, as this is could have a large impact on my current project, and pre-emptive changes in strategy are always better than post-release changes. :)
Thanks, Brandon
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
