[fpc-pascal] FPC static linking of zlib
Michael Van Canneyt
michael at freepascal.org
Tue Apr 13 22:45:26 CEST 2010
On Tue, 13 Apr 2010, Matthias Klumpp wrote:
> On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen <micha at neli.hopto.org>
> wrote:
>> Matthias Klumpp wrote:
>>> If you build the package using lazbuild, lintian (the Debian policy
>>> checker
>>> tool) throws an error described here:
>>> http://lintian.debian.org/tags/embedded-zlib.html
>>
>> paszlib is a pascal implementation of compression. How is that check
>> performed? Maybe it triggers on some specific function name?
> I'll ask someone.
>
>> I'm not sure if some version of zlib was translated to pascal; therefore
>> having the same security issues, or if it was written from scratch, so
>> that it won't have those security issues?
> Not sure...
> I should say that WinFF and easyMp3Gain do not use any ZLib function, so
> ZLib should not be in the binary.
When I use ldd to get the library dependencies, I get the following list of libraries:
home: >ldd bin/easymp3gain
linux-vdso.so.1 => (0x00007fff17fff000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f6de8258000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f6de803c000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f6de7a31000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f6de7785000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f6de753e000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f6de7277000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f6de7072000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f6de6e6e000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f6de6c25000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6de6a09000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f6de67e9000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f6de6566000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f6de6362000)
libc.so.6 => /lib/libc.so.6 (0x00007f6de5ff3000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f6de5dd7000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f6de5b2d000)
libm.so.6 => /lib/libm.so.6 (0x00007f6de58a9000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f6de569d000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f6de549a000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f6de5298000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f6de5092000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f6de4e69000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f6de4be4000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f6de49b2000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f6de47a0000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f6de4596000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f6de4394000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f6de4189000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f6de3f80000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f6de3d76000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007f6de3b48000)
librt.so.1 => /lib/librt.so.1 (0x00007f6de3940000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6de858e000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f6de36fb000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007f6de3470000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007f6de3266000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007f6de304b000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f6de2e25000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f6de2c21000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f6de2a18000)
libz.so.1 => /lib/libz.so.1 (0x00007f6de2801000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f6de25fe000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f6de23f9000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f6de21e0000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007f6de1fc2000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00007f6de1d99000)
As you can see, it uses libz (or zlib) but dynamically, probably through some library dependency.
So I have no idea why they think it is linked statically. I searched the sources, but found
no direct dependency on paszlib or zlib, but there is an indirect dependency, because the paszlib
units are used. I think the jpeg and png support are the cause of this.
If you add the -s option to the compiler command line, in the link.res file that is then
generated when compiling, you can see that the paszlib unit is used.
Maybe they look for a function name (as suggested by Micha). In that case you should make
clear that zlib is not linked statically, but that paszlib simply contains a function with
the same name.
Michael.
More information about the fpc-pascal
mailing list