Results 1 to 9 of 9

Thread: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

  1. #1

    Default qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    I'm running openSUSE 11.3 on a number of machines, including my laptop.

    On it, when starting qgis today (I hadn't used it for about two months) it reports:

    Code:
    libpng error: Incompatible libpng version in application and library
    And then it basically does not work, as no icons are shown and no maps (as they also involve PNG images)

    Weird thing is, I have the same setup on a same architecture desktop, and it all works perfectly there.

    I have checked:

    Code:
    ldd `which qgis` |grep png
            libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f5962e11000)
    Code:
    qgis &
    lsof -p $! |grep png
    qgis    8927 licehunt  mem    REG                8,2   170984   963988 /usr/lib64/libpng14.so.14.3.0
    
    md5sum /usr/lib64/libpng14.so.14.3.0
    32f592c41558cb3c1d3c81018339c981  /usr/lib64/libpng14.so.14.3.0
    
    md5sum `which qgis`
    080316397b024f04067ba78b511dd80f  /usr/bin/qgis
    The results, MD5 hashes included, are exactly the same on both machines. On one of them qgis works, on the other it starts but no icons/graphics are displayed, making it unusable.

    I have tried all the usual stuff, updating, reinstalling, running ldconfig, removing config/state files from $HOME, running as different user, etc., etc. to no avail.

    Any and all ideas are much appreciated.

  2. #2

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Interestingly, I have exactly the same issue with Merkaartor :-/

  3. #3

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Probably a library in the dependency tree is using PNG 1.2.
    Code:
    ldd /usr/bin/merkaartor | fgrep png
    should only return a line
    Code:
            libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f9c4d20a000)
    You probably get both libpng14 and libpng12?

    I suppose it is an Application:Geo vs Packman problem.

  4. #4

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Hi, thanks for your reply.

    Quote Originally Posted by RedDwarf View Post
    Probably a library in the dependency tree is using PNG 1.2.
    That was my first guess, but nothing in there appears to be using libpng12 (although it is installed in my systems).

    Code:
    ldd /usr/bin/merkaartor | fgrep png
    should only return a line
    Code:
            libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f9c4d20a000)
    You probably get both libpng14 and libpng12?
    Negative. Only libpng14, as expected:

    Code:
    ldd `which merkaartor` | fgrep png
            libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f09f7eb9000)
    Funny thing is, it works fine on one computer but not in another, very similar one. Both run opensuse 11.3 and much the same software.

    I suppose it is an Application:Geo vs Packman problem.
    As in a different libpng14 in one vs the other? Good point, worth looking into that. I'll report back if anything interesting there.

  5. #5

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Quote Originally Posted by licehunter View Post
    Negative. Only libpng14, as expected:
    You already put that in your first post, sorry.
    Well, then it seems something is dlopening libpng... but no idea what or how to know that easily.

    Quote Originally Posted by licehunter View Post
    As in a different libpng14 in one vs the other? Good point, worth looking into that. I'll report back if anything interesting there.
    No, more like "libgdal1" from Application:Geo being compiled with libpng14 and the one from Packman with libpng12.

    With some luck a
    Code:
    rpm -e --test libpng12-0
    will show which package is the problem (plus others, not related to the problem, you will need to guess from the name). But if the packager didn't put the dependency manually, if it's being dlopened then that will not work.

    You can also try to force the removing of libpng12-0, ignoring dependencies. With some look the error message will change and will help to know where the problem is.

    Failing all that... you will need to manually compare the list of installed packages in both machines. I still expect the problematic one to have a package from Packman that uses libpng12.

  6. #6

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Quote Originally Posted by RedDwarf View Post
    Well, then it seems something is dlopening libpng... but no idea what or how to know that easily.
    Getting this more weird... in my system, where it works, nothing dlopens libpng. There is still the posibility that in your non working system it is used, but...

    To verify, create a file preload.c with

    Code:
    #define _GNU_SOURCE
    #include <dlfcn.h>
    #include <stdio.h>
    
    void* dlopen(const char *file, int mode)
    {
        static void* (*o_dlopen) (const char *file, int mode) = 0;
        printf("dlopen was called for %s\n", file);
        if(!o_dlopen)
            o_dlopen = (void*(*)(const char *file, int mode)) dlsym(RTLD_NEXT, "dlopen");
        return (*o_dlopen)(file, mode);
    }
    and compile it with
    Code:
    gcc -fPIC -shared -o preload.so preload.c -ldl
    And then run qgis/merkaartor as
    Code:
    LD_PRELOAD=./preload.so $(which qgis)
    This way it will output the list of dlopened libraries.

  7. #7

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    RedDwarf, thank you for your extensive reply.

    Quote Originally Posted by RedDwarf View Post
    Getting this more weird... in my system, where it works, nothing dlopens libpng. There is still the posibility that in your non working system it is used, but...

    To verify, create a file preload.c with
    Done, and run:

    Code:
    # This is the machine where it all works, I'll call it RIGHT:
    LD_PRELOAD=./preload.so $(which qgis) |sort >dlcalls-right.txt
    grep png dlcalls-right.txt
    (no output)
    
    # This is the machine where it doesn't work, I'll call it WRONG:
    LD_PRELOAD=./preload.so $(which qgis) |sort >dlcalls-wrong.txt
    grep png dlcalls-wrong.txt
    (no output)
    
    # Let us compare:
    # (using 'uniq' for brevity, as some plugins are enabled in one
    # installation but not the other.)
    diff -u <(uniq dlcalls-right.txt) <(uniq dlcalls-wrong.txt)
    --- /dev/fd/63  2010-10-15 13:37:49.462021177 +0000
    +++ /dev/fd/62  2010-10-15 13:37:49.462021177 +0000
    @@ -1,4 +1,4 @@
    -dlopen was called for libproj.so.0
    +dlopen was called for libproj.so
     dlopen was called for libwacomcfg
     dlopen was called for libwacomcfg.so.0
     dlopen was called for libXcursor.so.1
    @@ -35,6 +35,9 @@
     dlopen was called for /usr/lib64/python2.6/lib-dynload/time.so
     dlopen was called for /usr/lib64/python2.6/lib-dynload/unicodedata.so
     dlopen was called for /usr/lib64/python2.6/lib-dynload/zlib.so
    +dlopen was called for /usr/lib64/python2.6/site-packages/osgeo/_gdalconst.so
    +dlopen was called for /usr/lib64/python2.6/site-packages/osgeo/_gdal.so
    +dlopen was called for /usr/lib64/python2.6/site-packages/osgeo/_ogr.so
     dlopen was called for /usr/lib64/python2.6/site-packages/PyQt4/QtCore.so
     dlopen was called for /usr/lib64/python2.6/site-packages/PyQt4/QtGui.so
     dlopen was called for /usr/lib64/python2.6/site-packages/PyQt4/QtNetwork.so
    @@ -51,6 +54,9 @@
     dlopen was called for /usr/lib64/qgis/libgeorefplugin.so
     dlopen was called for /usr/lib64/qgis/libgpsimporterplugin.so
     dlopen was called for /usr/lib64/qgis/libgpxprovider.so
    +dlopen was called for /usr/lib64/qgis/libgrassplugin.so
    +dlopen was called for /usr/lib64/qgis/libgrassprovider.so
    +dlopen was called for /usr/lib64/qgis/libgrassrasterprovider.so
     dlopen was called for /usr/lib64/qgis/libinterpolationplugin.so
     dlopen was called for /usr/lib64/qgis/libmemoryprovider.so
     dlopen was called for /usr/lib64/qgis/libnortharrowplugin.so
    @@ -76,11 +82,12 @@
     dlopen was called for /usr/lib64/qt4/plugins/imageformats/libqmng.so
     dlopen was called for /usr/lib64/qt4/plugins/imageformats/libqsvg.so
     dlopen was called for /usr/lib64/qt4/plugins/imageformats/libqtiff.so
    +dlopen was called for /usr/lib/gdalplugins/gdal_GRASS.so
    +dlopen was called for /usr/lib/gdalplugins/ogr_GRASS.so
     dlopen was called for /usr/share/qgis/python/qgis/core.so
     dlopen was called for /usr/share/qgis/python/qgis/gui.so
     dlopen was called for wacomcfg
     dlopen was called for wacomcfg.so.0
     Loaded : fTools (package: fTools)
    -Loaded : OpenStreetMap plugin (package: osm)
     Loaded : Plugin Installer (package: plugin_installer)
     Python support ENABLED :-)
    What does stand out there is the use of libproj.so on one machine vs. libproj.so.0 on the other, I have no idea why that is, except that:

    Code:
    # in WRONG machine:
    rpm -e --test libproj0
    ....
            libproj0 = 4.7.0-1.1 is needed by (installed) proj4-4.7.0-1.1.x86_64
    proj4 is installed on WRONG but not on RIGHT. Still, libproj0 does not depend on libpng so that's a dead end.

    As for RPM dependencies:

    Code:
    ssh RIGHT "rpm -e --test libpng12-0" 2>&1 |sort >rpmtest-right.txt
    ssh WRONG "rpm -e --test libpng12-0" 2>&1 |sort >rpmtest-wrong.txt
    diff -u rpmtest-right.txt rpmtest-wrong.txt  |grep "^[-+]"
    --- rpmtest-right.txt   2010-10-15 13:47:52.000000000 +0000
    +++ rpmtest-wrong.txt   2010-10-15 13:48:09.000000000 +0000
    +       libpng12.so.0()(64bit) is needed by (installed) LabPlot-1.6.0.1-33.1.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) MozillaSunbird-0.9-3.4.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) noteedit-2.8.1-185.1.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) qt3-3.3.8b-103.1.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) timidity-2.13.2-253.1.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) transfig-3.2.5a-6.1.x86_64
    +       libpng12.so.0()(64bit) is needed by (installed) wxWidgets-2.8.10.1-10.8.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) LabPlot-1.6.0.1-33.1.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) MozillaSunbird-0.9-3.4.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) qt3-3.3.8b-103.1.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) timidity-2.13.2-253.1.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) transfig-3.2.5a-6.1.x86_64
    +       libpng12.so.0(PNG12_0)(64bit) is needed by (installed) wxWidgets-2.8.10.1-10.8.x86_64
    None of which appear to be used by qgis/merkaartor.

    Next I'll try your suggestion to remove libpng12 from the offending machine and see what happens. Thanks again for your kind assistance.

  8. #8

    Default Re: qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    Ok, I have now also tried removing libpng12-0 (breaking dependencies) and it's made no difference whatsoever

  9. #9

    Default [SOLVED] qgis (Quantum GIS) reports incompatible libpng version in one installation, not in another

    YESSS!!!!

    Turned out I had a dangling libgdal0 (alongside libgdal1) on my bad system. I have removed it and now everything works like a charm.

    Not quite sure what the interaction was there which was causing the problem but as long as it works I'm happy.

    Thank you so much for your help RedDwarf, I would have never been able to figure it out without it, and I learned a couple of new tricks too.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •