[QGIS-trac] Re: [Quantum GIS] #1548: Python gui.so links to wrong QGIS libs when more than one version of QGIS is installed

Quantum GIS qgis at qgis.org
Wed Feb 18 16:14:12 EST 2009


#1548: Python gui.so links to wrong QGIS libs when more than one version of QGIS
is installed
--------------------------------------------------------------+-------------
        Reporter:  timlinux                                   |         Owner:  wonder                  
            Type:  bug                                        |        Status:  new                     
        Priority:  critical: causes crash or data corruption  |     Milestone:  Version 1.1.0           
       Component:  Build/Install                              |       Version:  HEAD                    
      Resolution:                                             |      Keywords:  python libraries version
Platform_version:  Ubuntu Linux 8.10 x86_64                   |      Platform:  Linux                   
        Must_fix:  Yes                                        |   Status_info:  0                       
--------------------------------------------------------------+-------------
Comment (by timlinux):

 Hi Martin

 Reading back to my original post, I see I didnt explain something well. I
 am not trying to '''run''' two concurrent versions from the same location
 (as you say some things obviously wont work in this context like the fact
 that the QGIS binary is being overwritten). I am however trying to
 '''install''' two versions to the same location (using only the last
 installed at any time though). Let me explain better:

 I have two QGIS source directories, one for trunk and one for stable. Each
 one has its own build dir. And both install to the same prefix. When I
 want to work with QGIS 1.0.x I run a make install in the stable source dir
 build directory and then run QGIS. Same thing for QGIS 1.1. I have
 followed this practice for some time without issues. Recently things have
 changed - I guess since we started 1.1 lib name versioning and the
 possibility arrived for linking to the two libs.

 "
 But imagine that it would be possible to have pyqgis modules core.so.1.0
 and core.so.1.1 in the same path. When you open python console and type:
 import qgis.core - how should the interpreter know which module are you
 asking for?"

 My expectation was that if core.so is linked to only one qgis_core lib,
 the interpreter should use the one linked to.

 "To my knowledge, python fails to load the module if you try to rename it
 from core.so to core.so.X.Y. "

 Ok just having gui.so and core.so link to only one lib would be a
 satisfactory solution here.

 "The problem with the linking (pyqgis modules linking to both 1.0 and 1.1
 libs) is surely caused by the mixture of two different builds in your
 build directory. Doing a clean compilation will fix the problem. I don't
 know how to force the linker to choose library with right soname. As far
 as I understand it, the linker checks for soname of the shared object
 you're linking against and then dynamic linker loads the library with
 correct soname. "

 This is the heart of the matter. Note that I am working with a clean build
 directory i.e. it contains no old object files from pre 1.1.  For some
 reason in recent weeks something has changed such that  overwriting
 installs between two different QGIS version causes odd linking in the
 python generated libs.

 I appreciate that my useage is an edge case however as I mentioned above,
 my approach used to work fine until the last 3 or 4 weeks (guessing on
 timeframe here). I just deleted my build dir in trunk sources and built
 again into my standard prefix to double / triple check and I still get the
 same cross linking side effect:

 {{{
 [qgis] ldd gui.so  | grep qgis
         libqgis_core.so.1.1 => /home/timlinux/apps/lib/libqgis_core.so.1.1
 (0x00007feb02f1a000)
         libqgis_gui.so.1.0 => /home/timlinux/apps/lib/libqgis_gui.so.1.0
 (0x00007feb020ce000)
         libqgis_core.so.1.0 => /home/timlinux/apps/lib/libqgis_core.so.1.0
 (0x00007feafacaa000)
 }}}

 As such I am not ready to close this bug as invalid at this point as there
 is definately something odd going on...

 Best regards

 Tim

-- 
Ticket URL: <https://trac.osgeo.org/qgis/ticket/1548#comment:2>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats


More information about the QGIS-trac mailing list