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 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.

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.

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.

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

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

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.

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

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.

file

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!

Michael Van Canneyt wrote

libz.so.1 => /lib/libz.so.1 (0x00007f6de2801000) As you can see, it uses libz (or zlib) but dynamically, probably through some library dependency.

I think this dynamic library dependency is caused by e.g. gtk, not directly by application or lcl or fcl directly.

Micha

Yes, that is what I meant, maybe I didn't express that clear enough.

Michael.