search

bgrabitmap / bgrabitmap

📜 BGRABitmap graphics library made with Lazarus (Free Pascal).
https://bgrabitmap.github.io/
197 stars 31 forks source link

BGRABitmapPack pulls too many libraries #253

Closed olivluca closed 4 months ago

olivluca commented 4 months ago

I wrote a project using lazarus 2.0.12 with BGRABitmapPack (V10.6.5 installed from the online package manager) under linux. The compiled project used just a handful of so files:so I could easily move the executable from my development machine to the server

$ ldd /opt/adam/adam
        linux-vdso.so.1 (0x00007ffc6c15b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8caf3c4000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8caf3be000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8caf1ea000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8caf3ef000)

Now, if I try to build the same project with lazarus 2.2 6 (BGRABitmapPack V11.4) or lazarus 3.2 (BGRABitmapPack V11.5.4) it pulls a lot more libraries not available on the server

$ ldd adam
        linux-vdso.so.1 (0x00007ffcc89f5000)
        libgdk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007eff532a4000)
        libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007eff53276000)
        libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007eff53217000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eff530df000)
        libgthread-2.0.so.0 => /lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007eff530da000)
        libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007eff530d2000)
        libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007eff53069000)
        libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 (0x00007eff52f45000)
        libgtk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007eff52a00000)
        libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007eff52f1c000)
        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007eff528be000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff526dd000)
        libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007eff52f09000)
        libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007eff524fd000)
        libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007eff52ebe000)
        libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007eff52eb1000)
        libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007eff52eac000)
        libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007eff52e96000)
        libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007eff52e89000)
        libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007eff52e7c000)
        libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007eff52e77000)
        libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007eff52e72000)
        libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007eff52e6a000)
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007eff524e8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff52409000)
        libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eff523d3000)
        libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007eff52340000)
        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007eff52334000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007eff5229a000)
        libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 (0x00007eff5227e000)
        libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 (0x00007eff52273000)
        libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eff5216f000)
        libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007eff520c4000)
        libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eff51ff9000)
        libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007eff52e5f000)
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007eff51fcf000)
        libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007eff51fc1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007eff51fa2000)
        libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007eff51f87000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff51f82000)
        /lib64/ld-linux-x86-64.so.2 (0x00007eff53381000)
        libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007eff51f1f000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007eff51ef1000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007eff51ec6000)
        libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007eff51eba000)
        libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eff51e8e000)
        libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eff51e81000)
        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007eff51e7c000)
        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007eff51c00000)
        libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007eff51e23000)
        libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eff51bdd000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007eff51e0d000)
        libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007eff51bd0000)

Considering that both the "ancient" version and the new one have LCL as a dependency, what changed?

olivluca commented 4 months ago

I upgraded BGRABitmapPack to version 11.6.2 (from the online package manager), same problem.

circular17 commented 4 months ago

Hello @olivluca and thanks for popping by.

I admit I don't know what are the changes that would require so many libraries. I can see two ways you could investigate this:

Regards

olivluca commented 4 months ago

I don't know if the change comes from lazarus or BGRA (probably the former), but as I discussed on the lazarus mailing list the workaround is to use the nogui widgetset. I tried your suggestion but:

fredvs commented 4 months ago

@olivluca

In your first post:

 ldd /opt/adam/adam
        linux-vdso.so.1 (0x00007ffc6c15b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8caf3c4000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8caf3be000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8caf1ea000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8caf3ef000)

The result shows that no graphic dependencies are needed. Is your "adam" program a console program?

olivluca commented 4 months ago

Yes, it's an http server.

fredvs commented 4 months ago

Hum, without any graphic-rendered things (no use of Lazarus LCL)? Are you using BGRABitmap then only as console program?

If so, indeed strange that all that dependencies are needed. In your lpr-program source, do you have Interfaces, added in your uses section?

If so what if you remove it?

fredvs commented 4 months ago

Important too: did you use the -B (build all) parameter when you changed the defines (like -dBGRABITMAP_DONT_USE_LCL, ...)

olivluca commented 4 months ago

There was no interfaces unit in the original program that compiled and worked fine with lazarus 2.0.12. I had to add it in order to compile it with lazarus 3.2. I'm only using BGRABitmap to convert any input image (sent by the browser) to jpeg and scale it to a fixed size, it worked fine then and it seems to be working fine, with no extra libraries, with the nogui widgetset.

olivluca commented 4 months ago

Important too: did you use the -B (build all) parameter when you changed the defines (like -dBGRABITMAP_DONT_USE_LCL, ...)

of course

fredvs commented 4 months ago

I had to add it in order to compile it with lazarus 3.2.

Ha, ok, this is the problem. May I ask you what error you get if you remove Interfaces,?

olivluca commented 4 months ago

No, that's not the problem,that's just a symptom: interfaces now is needed because something else is using the currently selected widgetset functions, it wasn't needed in 2020 because nothing pulled in those functions.

The errors are like this one (there are many more functions missing):

Warning: linker: /usr/bin/ld: 
/home/luca/Datos/laz_3_2/lcl/lib/LCLBase/3.2.2/x86_64-linux/Default/wsimglist.o: 
in function `REGISTERCUSTOMIMAGELISTRESOLUTION':
wsimglist.pp(265,0) Error: linker: undefined reference to 
`WSRegisterCustomImageListResolution'
fredvs commented 4 months ago

Yes, it is exactly my thinking.

Adding interfaces has for result a big need of dependencies. Now the game is to find what unit needs interfaces suddenly in lazarus 3.2., even if no GUI is used.

In the errors you get, is it only at linking and so compilation is ok? If so, it should be because a unit somewhere in the uses section needs LCL.

fredvs commented 4 months ago

Sometimes when opening a old Lazarus project, the new Lazarus version add some code on original source.

Is it in one of your unit in the uses section a LCL dependent unit like: Forms, Controls, Graphics, or Dialogs ?

If so, what removing it ( with Interfaces, too )?

olivluca commented 4 months ago

No other change was needed/automatically introduced. I only had to remove the dependency on the LazWebExtra package that is no longer available (though even without it the project compiles just fine). And, yes, compilation is ok (it only fails if I use those defines), linking fails unless I add the Interfaces unit.

(Edit: now I see that LazWebExtra in 2.0.12 was a dummy package with no files, no wonder it isn't needed).

fredvs commented 4 months ago

And, yes, compilation is ok (it only fails if I use those defines), linking fails unless I add the Interfaces unit.

So there is somewhere in your code a unit that needs LCL. Could you give the list of units used in your uses sections (before and after implementation)?

fredvs commented 4 months ago

In zip file a simple console Lazarus project that uses the nogui package and custom option for compiler -dBGRABITMAP_DONT_USE_LCL :

bgra_nogui.zip

Here with Lazarus 2.2.6 the compilation + link + run is ok. The result of ldd:

$ ldd /home/fred/project1
    linux-vdso.so.1 (0x00007ffc8e3a5000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000761e19a38000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000761e19a33000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000761e19800000)
    /lib64/ld-linux-x86-64.so.2 (0x0000761e19a59000)
olivluca commented 4 months ago

Shoot me, BGRABitmap doesn't build here with -dBGRABITMAP_DONT_USE_LCL

fredvs commented 4 months ago

No, I prefer to find why it does not work for you. (And not easy without seeing your code...)

Is it a big project with no possibility to give a resume of what units are used?

fredvs commented 4 months ago

BGRABitmap doesn't build here with -dBGRABITMAP_DONT_USE_LCL

Not sure that I understood. Are you talking about the bgra_nogui project of my previous post or are you talking about your program (or both)?

fredvs commented 4 months ago

In your .lpi file, do you have this ?:

   ...

   <RequiredPackages>
      <Item>
        <PackageName Value="BGRABitmapPack4NoGUI"/>
      </Item>
    </RequiredPackages>

     ....

      <Other>
      <CustomOptions Value="-dBGRABITMAP_DONT_USE_LCL -B"/>
     </Other>

       ....

Sorry, I dont have other idea at the moment.

olivluca commented 4 months ago

Thank you! That was it. The dependency I had (and worked with no extra library) was on the BGRABitmapPack package, not the BGRABitmapPack4NoGUI one. In fact I didn't even know the latter existed (the online package manager only lists the former). No need for any extra options and no need to include the Interfaces unit.

circular17 commented 4 months ago

Hi @fredvs,

I hope this message finds you well. I wanted to take a moment to express my appreciation for your assistance in helping @olivluca resolve the compilation issue with their Lazarus project. Your detailed guidance highlighted the use of the BGRABitmapPack4NoGUI package.

@olivluca I am glad your problem was finally solved. Even tough I understand you may not be comfortable sharing your actual program, I gather from this discussion that providing a sample project is always helpful.

Regards

olivluca commented 4 months ago

Sure, unfortunately this is an internal piece of code that I cannot share at the moment. By checking the commit history It turns out that when I added BGRABitmap to this project, the nogui package was already available, so my using of the normal package was a mistake even if it worked at the time.