FPC static linking of zlib

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

FPC static linking of zlib

Matthias Klumpp
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Michael Van Canneyt


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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Matthias Klumpp
> 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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Micha Nelissen
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Matthias Klumpp
On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen <[hidden email]>
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Vincent Snijders-2
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Michael Van Canneyt
In reply to this post by Matthias Klumpp


On Tue, 13 Apr 2010, Matthias Klumpp wrote:

> On Tue, 13 Apr 2010 22:00:58 +0200, Micha Nelissen <[hidden email]>
> 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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Matthias Klumpp
On Tue, 13 Apr 2010 22:45:26 +0200 (CEST), Michael Van Canneyt
<[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Micha Nelissen
In reply to this post by Michael Van Canneyt
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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC static linking of zlib

Michael Van Canneyt


On Wed, 14 Apr 2010, Micha Nelissen wrote:

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

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

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal