Re: [fpc-pascal] FPC static linking of zlib
On Tue, 13 Apr 2010 22:45:26 +0200 (CEST), Michael Van Canneyt wrote: > [...] > > 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. Now I got the confirmation from a developer who is developing Lintian that this is a false positive. (A bug in Lintian) FPC uses a translated header which matches the regex Lintian uses to detect embedded ZLibs. Curious that this has been overriden for over four years and noone ever asked if it could be a bug in the Debian tool instead of FPC. Thnks for your clearification! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC static linking of zlib
Matthias Klumpp schreef: 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. Just guessing or speculating: WinFF is a LCL application and that includes png support with a png reader that uses zlib for compression? All of the above could be false, though. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC static linking of zlib
On Tue, 13 Apr 2010, Matthias Klumpp wrote: On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen 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 => (0x7fff17fff000) libX11.so.6 => /usr/lib/libX11.so.6 (0x7f6de8258000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x7f6de803c000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x7f6de7a31000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x7f6de7785000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7f6de753e000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x7f6de7277000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x7f6de7072000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x7f6de6e6e000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x7f6de6c25000) libpthread.so.0 => /lib/libpthread.so.0 (0x7f6de6a09000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x7f6de67e9000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x7f6de6566000) libdl.so.2 => /lib/libdl.so.2 (0x7f6de6362000) libc.so.6 => /lib/libc.so.6 (0x7f6de5ff3000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7f6de5dd7000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x7f6de5b2d000) libm.so.6 => /lib/libm.so.6 (0x7f6de58a9000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x7f6de569d000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x7f6de549a000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x7f6de5298000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x7f6de5092000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x7f6de4e69000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x7f6de4be4000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x7f6de49b2000) libXext.so.6 => /usr/lib/libXext.so.6 (0x7f6de47a) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x7f6de4596000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x7f6de4394000) libXi.so.6 => /usr/lib/libXi.so.6 (0x7f6de4189000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x7f6de3f8) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x7f6de3d76000) libpcre.so.3 => /lib/libpcre.so.3 (0x7f6de3b48000) librt.so.1 => /lib/librt.so.1 (0x7f6de394) /lib64/ld-linux-x86-64.so.2 (0x7f6de858e000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x7f6de36fb000) libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x7f6de347) libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x7f6de3266000) libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x7f6de304b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x7f6de2e25000) libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x7f6de2c21000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x7f6de2a18000) libz.so.1 => /lib/libz.so.1 (0x7f6de2801000) libXau.so.6 => /usr/lib/libXau.so.6 (0x7f6de25fe000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x7f6de23f9000) libresolv.so.2 => /lib/libresolv.so.2 (0x7f6de21e) libselinux.so.1 => /lib/libselinux.so.1 (0x7f6de1fc2000) libexpat.so.1 => /lib/libexpat.so.1 (0x7f6de1d99000) 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. ___
Re: [fpc-pascal] FPC static linking of zlib
On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC static linking of zlib
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'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? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC static linking of zlib
> This bug report does not make any sense. > > 1. FPC does link executables to dynamic libraries if you ask it to. > I do it every day. It does - but zlib is included. > 2. zlib is linked dynamically if you ask it to be. If the zlib unit is > used, > then zlib is linked dynamically. If they use paszlib, then the answer > is that > Paszlib is *NOT* zlib, and if that is used, then debian rules simply > don't apply. > > So what is the problem ? I better show you the concrete example I'm working on. I'm the maintainer of easymp3gain, a package developed using Lazarus LCL and FPC. If you have Debian Sid installed, you can easily grab the package source using the command dget http://mentors.debian.net/debian/pool/main/e/easymp3gain/easymp3gain_0.5.0-3.dsc 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 As you can see, the FPC/LCL packages Lazarus and WinFF are also affected of this behavior. Why do we get this error of zlib beeing statically linked by FPC? Regards Matthias P.S: The full source code of easymp3gain without Debian packaging & patches can be found here: http://mentors.debian.net/debian/pool/main/e/easymp3gain/easymp3gain_0.5.0.orig.tar.gz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC static linking of zlib
On Tue, 13 Apr 2010, Matthias Klumpp wrote: Hello! Some time ago, bug #472304 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472304) was filed against Debian, cause FPC does not link executables dynamically. This bug should have been fixed with FPC 2.4.0 FPC does link executables dynamically ? But a pascal-only program is a single binary that does not link to any library, for the simple reason that such libraries do not exist. Unfortunately, the binaries generated by FPC 2.4.0 on Debian seem to link zlib statically, which is a clear violation of the Debian policy and might prevent packages compiled using FPC from beeing accepted into Debian. Could someone please give some feedback about this bug? When does it get fixed? Why is it not already fixed? Or is it already done in FPC and there's just some parameter missing? This bug report does not make any sense. 1. FPC does link executables to dynamic libraries if you ask it to. I do it every day. 2. zlib is linked dynamically if you ask it to be. If the zlib unit is used, then zlib is linked dynamically. If they use paszlib, then the answer is that Paszlib is *NOT* zlib, and if that is used, then debian rules simply don't apply. So what is the problem ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC static linking of zlib
Hello! Some time ago, bug #472304 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472304) was filed against Debian, cause FPC does not link executables dynamically. This bug should have been fixed with FPC 2.4.0 Unfortunately, the binaries generated by FPC 2.4.0 on Debian seem to link zlib statically, which is a clear violation of the Debian policy and might prevent packages compiled using FPC from beeing accepted into Debian. Could someone please give some feedback about this bug? When does it get fixed? Why is it not already fixed? Or is it already done in FPC and there's just some parameter missing? Thanks and kind regards Matthias Klumpp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
