On Tue, 13 Apr 2010, Matthias Klumpp wrote:
On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen <mi...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
