How to avoid linking zlib objs into the binary mor

I've been googling around for a zlib sample of how to decode gzip/deflate http encoding by only using ZLib unit (Delphi 7). I've been using Indy 10 for that but then I ran into an article saying many 3rd party components implemented their own zlib helpers eventually causing multiple zlib objects linked into the output file. I have this huge project and looking for ways to reduce the size. I did a search on the binary and turned out I had at least 4 copies of zlib linked in.

Is there a way to avoid linking zlib obj files into the binary more than once? Can I make Indy not to use/import zlib at all?

回答1:

Is there a way to avoid linking zlib obj files into the binary more than once?

No there is not. The linking .obj files is private to each unit. There is no way for you to detect from one unit that some other unit has linked a .obj file.

回答2:

Are you sure it's linking binary identical copies? What if the differences matter to the respective libraries linking zlib/zlibex? If you really want to solve this problem, you should zap the INdy packages and DCU/DCP binaries that came with Delphi, and build everything from source yourself.

List for us, exactly what libraries you are using that contain ZLib. Now obtain full source code for each, and built them all yourself. Make them all depend (at designtime) on a common package, that contains the ZLib sources, so that the ZLib sources won't be loaded at designtime, multiple times. Now do the same for your non-package environment; Make sure that only one copy of the ZLib source files exist, built them into obj files using a C compiler (ZLib is a C package), and then link against those, and test them to be sure they all work. If you're not up for testing everything after changing zlib versions, abandon your attempt now. If you can't or don't want to learn to read C code, abandon your attempt also.

In Delphi 2009 Enterprise and ARchitect, until XE, readers need to be wary that this this starts a domino effect of cascading problems which are not possible to fully recover from, if for example, you rely on DataSnap, which relies on the exact ABI of the Indy BPl that ships with Delphi. Of course on an ancient version like Delphi 7, you can solve all these problems, and rebuild them yourself on Delphi 7.

I can't guess for you which libraries you have that might contain duplicates of Zlib, but some common places I have found it are: Any kind of zip/archive library (TurboPower Abbrevia), network libraries (like Indy), and so on. The JEDI JCL contains a copy of ZLib, and contains its own Zlib based compression components, which if you are using them, would get linked in. You have to go find stuff in your own source code. If you are that suprised to find 4 copies of Zlib (perhaps they are different versions of Zlib, even), I can guarantee you'll find even more surprises if you start exploring your code and your component source code.