Mac OS X: QGIS 1.0 Preview 2 Crashes

[Dan Dittmann]

I am unable to run QGIS 1.0 Preview 2 because the application quits  
out before completely launching.

Numerous messages are left behind in the Console.

11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::undo()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::cut()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::copy()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::paste()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::undo()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::cut()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::copy()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect: No such slot QgsComposer::paste()
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
Object::connect:  (receiver name: 'QgsComposerBase')
11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Fatal Python  
error: Interpreter not initialized (version mismatch?)

The last message indicated the possibility of a problem relating to  
Python. A few months ago, I had updated to python.org's version and  
been using that rather than the system default. On that thought, I  
first updated to version 2.6 -- no change. I then tried the system  
default. To accomplish this, I removed the nonsystem version from my  
path, then restarted the system. After restart, my path checked out as  
expected and running which python showed me /usr/bin/python. Doing so  
however made no difference as QGIS still crashed with the same console  
messages.

Does anyone have any thoughts as to what else I should look at?

My set up is on Mac OS 10.5.5 + all security updates. The system  
version of python is 2.5.1. In addition, I have trashed the pref file  
as well as moved ~/.qgis temporarily to a different directory.

I will note the previous preview exhibited the same behavior as well,  
I just did not have the time to troubleshoot it.

Dan Dittmann

_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 13, 2008, at 7:55 PM, Dan Dittmann wrote:

> 11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
> Object::connect:  (receiver name: 'QgsComposerBase')
> 11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Fatal Python  
> error: Interpreter not initialized (version mismatch?)
>
> The last message indicated the possibility of a problem relating to  
> Python. A few months ago, I had updated to python.org's version and  
> been using that rather than the system default. On that thought, I  
> first updated to version 2.6 -- no change. I then tried the system  
> default. To accomplish this, I removed the nonsystem version from my  
> path, then restarted the system. After restart, my path checked out  
> as expected and running which python showed me /usr/bin/python.  
> Doing so however made no difference as QGIS still crashed with the  
> same console messages.
>

On OSX Qgis is very particular about which Python is used at runtime.  
Unfortunately, PyQt/SIP, and the Qgis python libraries, link directly  
to the Python framework binary, so only that Python binary can be used  
to load the Qgis python bindings.

Unlike other systems, on OSX a proper plugin/extension links in a  
different way to its parent than normal dynamic libraries - there is  
no direct link to the parent binary.  It expects to be loaded by that  
parent, and thus find all the functions it needs from the parent.

This makes it simple to to move the parent around (ie Python, Apache,  
PHP) or use different builds (but same version) of the parent (ie  
Apple Python 2.5 vs python.org Python 2.5).

How this affects Qgis/python: say Qgis is built with the Apple Python  
(like my Leopard Qgis), but you have the python.org python (2.5 or  
2.6) in your shell PATH.  Qgis starts up python, and finds  
python.org's python.  But the Qgis python binary parts link to the  
system python - total binary confusion, even though they may be the  
same version, and Qgis crashes.

So, installing Python 2.6 will cause trouble, if Qgis was built with  
either the system python or python.org python 2.5.  If Qgis was built  
with the python.org python 2.5, removing it will cause trouble also.

It would be nice if PyQt/SIP and Qgis properly linked to python (I  
think Qgis takes its cue from SIP), then it would be easier to switch  
between the system python 2.5 and python.org 2.5.

> Does anyone have any thoughts as to what else I should look at?
>
If Qgis crashed, look in Console.app for the crashlog.  If it's just  
quitting with no crash, turning on Qgis debugging may help find the  
problem (sorry, I don't remember how to do that).

> My set up is on Mac OS 10.5.5 + all security updates. The system  
> version of python is 2.5.1. In addition, I have trashed the pref  
> file as well as moved ~/.qgis temporarily to a different directory.
>

Which Qgis are you using - mine (framework-based) or Tom's all-in-one?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Dan Dittmann]

On Nov 13, 2008, at 8:35 PM, William Kyngesburye wrote:

> On Nov 13, 2008, at 7:55 PM, Dan Dittmann wrote:
>
>> 11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Warning:  
>> Object::connect:  (receiver name: 'QgsComposerBase')
>> 11/13/08 7:43:08 PM [0x0-0x1f01f].org.qgis.qgis[273] Fatal Python  
>> error: Interpreter not initialized (version mismatch?)
>>
>> The last message indicated the possibility of a problem relating to  
>> Python. A few months ago, I had updated to python.org's version and  
>> been using that rather than the system default. On that thought, I  
>> first updated to version 2.6 -- no change. I then tried the system  
>> default. To accomplish this, I removed the nonsystem version from  
>> my path, then restarted the system. After restart, my path checked  
>> out as expected and running which python showed me /usr/bin/python.  
>> Doing so however made no difference as QGIS still crashed with the  
>> same console messages.
>>
> On OSX Qgis is very particular about which Python is used at  
> runtime.  Unfortunately, PyQt/SIP, and the Qgis python libraries,  
> link directly to the Python framework binary, so only that Python  
> binary can be used to load the Qgis python bindings.
>
> Unlike other systems, on OSX a proper plugin/extension links in a  
> different way to its parent than normal dynamic libraries - there is  
> no direct link to the parent binary.  It expects to be loaded by  
> that parent, and thus find all the functions it needs from the parent.
>
> This makes it simple to to move the parent around (ie Python,  
> Apache, PHP) or use different builds (but same version) of the  
> parent (ie Apple Python 2.5 vs python.org Python 2.5).
>
> How this affects Qgis/python: say Qgis is built with the Apple  
> Python (like my Leopard Qgis), but you have the python.org python  
> (2.5 or 2.6) in your shell PATH.  Qgis starts up python, and finds  
> python.org's python.  But the Qgis python binary parts link to the  
> system python - total binary confusion, even though they may be the  
> same version, and Qgis crashes.
>
> So, installing Python 2.6 will cause trouble, if Qgis was built with  
> either the system python or python.org python 2.5.  If Qgis was  
> built with the python.org python 2.5, removing it will cause trouble  
> also.

This is sort of the idea I was operating on when I chose to remove  
python.org's version from my path.

> It would be nice if PyQt/SIP and Qgis properly linked to python (I  
> think Qgis takes its cue from SIP), then it would be easier to  
> switch between the system python 2.5 and python.org 2.5.
>
>> Does anyone have any thoughts as to what else I should look at?
>>
> If Qgis crashed, look in Console.app for the crashlog.  If it's just  
> quitting with no crash, turning on Qgis debugging may help find the  
> problem (sorry, I don't remember how to do that).

If I get ambitious, I'll poke around for this.
>
>
>> My set up is on Mac OS 10.5.5 + all security updates. The system  
>> version of python is 2.5.1. In addition, I have trashed the pref  
>> file as well as moved ~/.qgis temporarily to a different directory.
>>
>
> Which Qgis are you using - mine (framework-based) or Tom's all-in-one?

Tom's All in one.

I did just download your frameworks and your build of QGIS. That  
version works as expected.


Dan
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Martin Dobias]

On Fri, Nov 14, 2008 at 3:35 AM, William Kyngesburye
<woklist@...> wrote:
>
> It would be nice if PyQt/SIP and Qgis properly linked to python (I think
> Qgis takes its cue from SIP), then it would be easier to switch between the
> system python 2.5 and python.org 2.5.

William,

do you have any ideas how to improve the situation of QGIS python
support on OS X?
I don't know much about specifics of OS X but we could tweak python
support with your assistence if you describe what's going wrong.

Martin
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 4:41 AM, Martin Dobias wrote:

> On Fri, Nov 14, 2008 at 3:35 AM, William Kyngesburye
> <woklist@...> wrote:
>>
>> It would be nice if PyQt/SIP and Qgis properly linked to python (I  
>> think
>> Qgis takes its cue from SIP), then it would be easier to switch  
>> between the
>> system python 2.5 and python.org 2.5.
>
> William,
>
> do you have any ideas how to improve the situation of QGIS python
> support on OS X?
> I don't know much about specifics of OS X but we could tweak python
> support with your assistence if you describe what's going wrong.
>
> Martin

I think we're stuck with what we get from SIP/PyQt.  SIP is, I  
believe, what is setting the compile flags.  Even if Qgis post-
processed those flags, SIP and PyQt would still be built that way.

If it's what I think it is, I see in sipconfig.py:

_default_macros = {
...
'LFLAGS_PLUGIN': '-single_module -dynamiclib',

I could try a bug report to Riverbank... but for now we'll just have  
to put up with it, which means making sure the right python is the  
default for the Qgis build run.

Short details, so you know what's going on:

A plugin, or "module" on OSX doesn't use normal library linking to a  
parent, or loading, binary (library or program), as -dynamiclib -lfoo  
(or -dynamiclib -undefined dynamic_lookup for a parent program).

Instead it links as a bundle:

-bundle -bundle_loader /path/to/foo

The -bundle_loader acts in place of the -l flag, so the linker can  
find the symbols in the parent, but the library or program is not  
actually added to the module's link list.  And a bundle can't be  
linked to as a library.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 9:18 AM, William Kyngesburye wrote:

>> do you have any ideas how to improve the situation of QGIS python
>> support on OS X?
>> I don't know much about specifics of OS X but we could tweak python
>> support with your assistence if you describe what's going wrong.
>>
>> Martin
>
> I think we're stuck with what we get from SIP/PyQt.  SIP is, I  
> believe, what is setting the compile flags.  Even if Qgis post-
> processed those flags, SIP and PyQt would still be built that way.
>
> If it's what I think it is, I see in sipconfig.py:
>
> _default_macros = {
> ...
> 'LFLAGS_PLUGIN': '-single_module -dynamiclib',
>

Hmm, I started poking around more...  Where DOES Qgis get its python  
compile flags from?

My python/core/makefile has:

LFLAGS = -headerpad_max_install_names -bundle -F/System/Library/
Frameworks -framework Python -arch ppc -arch i386

BOTH -bundle AND -framework Python are there.  This is wrong - it's  
linking a bundle, but also linking directly to python, defeating the  
benefit of the bundle.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 10:20 AM, William Kyngesburye wrote:

> Hmm, I started poking around more...  Where DOES Qgis get its python  
> compile flags from?
>
sipconfig.py:class ModuleMakefile(Makefile)

> My python/core/makefile has:
>
> LFLAGS = -headerpad_max_install_names -bundle -F/System/Library/
> Frameworks -framework Python -arch ppc -arch i386
>
> BOTH -bundle AND -framework Python are there.  This is wrong - it's  
> linking a bundle, but also linking directly to python, defeating the  
> benefit of the bundle.
>
... Hmmm ...

I see a possible simple patch to sipconfig.py that can solve the  
problem at the root, so Qgis and even PyQt and SIP would be compiled  
correctly.  No changes needed in Qgis.

I'll have to get back to it this evening...

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Martin Dobias]

On Fri, Nov 14, 2008 at 5:20 PM, William Kyngesburye
<woklist@...> wrote:

> On Nov 14, 2008, at 9:18 AM, William Kyngesburye wrote:
>
>>> do you have any ideas how to improve the situation of QGIS python
>>> support on OS X?
>>> I don't know much about specifics of OS X but we could tweak python
>>> support with your assistence if you describe what's going wrong.
>>>
>>> Martin
>>
>> I think we're stuck with what we get from SIP/PyQt.  SIP is, I believe,
>> what is setting the compile flags.  Even if Qgis post-processed those flags,
>> SIP and PyQt would still be built that way.
>>
>> If it's what I think it is, I see in sipconfig.py:
>>
>> _default_macros = {
>> ...
>> 'LFLAGS_PLUGIN': '-single_module -dynamiclib',
>>
> Hmm, I started poking around more...  Where DOES Qgis get its python compile
> flags from?

All configuration for build of PyQGIS is in python/configure.py.in
(which is processed by CMake). As you correctly figured out already,
the flags come from sipconfig.ModuleMakefile.

Am I right that the problem applies only to bindings (based on
SIP/PyQt4), while implementation of embedded python (libqgispython) is
okay?

Martin
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 11:07 AM, Martin Dobias wrote:

> Am I right that the problem applies only to bindings (based on
> SIP/PyQt4), while implementation of embedded python (libqgispython) is
> okay?


Ah, there's a tricky one.  Is libqgispython meant to be a "library",  
linked by other plugins or the Qgis app?  Or is it more like a plugin,  
loaded by Qgis?

I see that none of Qgis, libqgis_* or python/qgis/*.so directly link  
libqgispython.  Yet it is compiled as a library (not bundle) and also  
links directly to the python binary.

If libqgispython is dynamically loaded by Qgis, thet it should also be  
compiled as a bundle and not linked to python.

If libqgispython is meant to be used as a library by other binaries  
(ie python extensions), then it still shouldn't link directly to  
python, but expect Python to be loaded in some way by whatever is  
linking to it.  It would have to compile with -undefined  
dynamic_lookup then.


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Martin Dobias]

On Fri, Nov 14, 2008 at 7:30 PM, William Kyngesburye
<woklist@...> wrote:

> On Nov 14, 2008, at 11:07 AM, Martin Dobias wrote:
>
>> Am I right that the problem applies only to bindings (based on
>> SIP/PyQt4), while implementation of embedded python (libqgispython) is
>> okay?
>
>
> Ah, there's a tricky one.  Is libqgispython meant to be a "library", linked
> by other plugins or the Qgis app?  Or is it more like a plugin, loaded by
> Qgis?
>
> I see that none of Qgis, libqgis_* or python/qgis/*.so directly link
> libqgispython.  Yet it is compiled as a library (not bundle) and also links
> directly to the python binary.
>
> If libqgispython is dynamically loaded by Qgis, thet it should also be
> compiled as a bundle and not linked to python.
>
> If libqgispython is meant to be used as a library by other binaries (ie
> python extensions), then it still shouldn't link directly to python, but
> expect Python to be loaded in some way by whatever is linking to it.  It
> would have to compile with -undefined dynamic_lookup then.

libqgispython is meant to be loaded dynamically by QGIS application on
startup. All python-related implementation is in this library, the
rest of application is "python-free", i.e. it doesn't use any
functions directly from python libs.

libqgispython is not meant to be used by anything else than QGIS
application itself.

The main reason of this implementation is that this way we can have
python support (python console and python plugins) optionally, and it
should make life easier for packagers. And second reason, if
libqgispython is not found (or can't be loaded for some reason) when
QGIS starts, nothing fatal happens, just python support is disabled.

I hope this makes things a little clearer...

Martin
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 3:58 PM, Martin Dobias wrote:

> libqgispython is meant to be loaded dynamically by QGIS application on
> startup. All python-related implementation is in this library, the
> rest of application is "python-free", i.e. it doesn't use any
> functions directly from python libs.
>
> libqgispython is not meant to be used by anything else than QGIS
> application itself.


So now the question is (and something I've wondered about) - just how  
does this python support work?  Does it execute the python program (as  
found in the user's PATH)?  Does it depend on linking to the python  
library to find some python start/init symbol?

I'm guessing it runs or loads the python executable, because of the  
problems we're having when other python binaries are found before the  
one used to build Qgis.  If this is the case, we just need to depend  
on the run/load of python to link in the python library, and  
libqgispython itself doesn't need to link directly to python.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Martin Dobias]

On Fri, Nov 14, 2008 at 11:11 PM, William Kyngesburye
<woklist@...> wrote:

> On Nov 14, 2008, at 3:58 PM, Martin Dobias wrote:
>
>> libqgispython is meant to be loaded dynamically by QGIS application on
>> startup. All python-related implementation is in this library, the
>> rest of application is "python-free", i.e. it doesn't use any
>> functions directly from python libs.
>>
>> libqgispython is not meant to be used by anything else than QGIS
>> application itself.
>
>
> So now the question is (and something I've wondered about) - just how does
> this python support work?  Does it execute the python program (as found in
> the user's PATH)?  Does it depend on linking to the python library to find
> some python start/init symbol?

We're using only direct API function calls to python C library, python
executable is _not_ being run.

To get libqgispython working properly, it's loaded from QGIS
application with following Qt's load hints:
- ResolveAllSymbolsHint
- ExportExternalSymbolsHint
See [1] for their documentation. If they're not used, python library
doesn't work correctly. There has been also some discussion on
pykde-list [2].

Martin

[1] http://doc.trolltech.com/4.3/qlibrary.html#LoadHint-enum
[2] http://lists.kde.org/?l=pykde&m=117190116820758&w=2
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 5:03 PM, Martin Dobias wrote:

>> So now the question is (and something I've wondered about) - just  
>> how does
>> this python support work?  Does it execute the python program (as  
>> found in
>> the user's PATH)?  Does it depend on linking to the python library  
>> to find
>> some python start/init symbol?
>
> We're using only direct API function calls to python C library, python
> executable is _not_ being run.
>
> To get libqgispython working properly, it's loaded from QGIS
> application with following Qt's load hints:

Ugh.  So, libqgispython is loaded more like a library, and it expects  
the python library to be loaded somehow - by the compiler linking -  
which is what we need to avoid.

I wonder if Qgis can load the python library in the same way it loads  
libqgispython, so that the python symbols are available to  
libqgispython when it's loaded?  Then it could load whichever python  
is "default", whatever that may mean, or have a Qgis preference (like  
setting the GRASS location) to let the user choose a Python to use.

Otherwise, whatever is done to make all the PyQt and Qgis python  
extensions "proper" won't matter, since libqgispython will be stuck  
with whichever python it was compiled with.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Martin Dobias]

On Sat, Nov 15, 2008 at 12:52 AM, William Kyngesburye
<woklist@...> wrote:

> On Nov 14, 2008, at 5:03 PM, Martin Dobias wrote:
>> We're using only direct API function calls to python C library, python
>> executable is _not_ being run.
>>
>> To get libqgispython working properly, it's loaded from QGIS
>> application with following Qt's load hints:
>
> Ugh.  So, libqgispython is loaded more like a library, and it expects the
> python library to be loaded somehow - by the compiler linking - which is
> what we need to avoid.

libqgispython expects that dynamic linker loads the python library.
But I don't understand why we need to avoid it. Are python
implementations on OS X incompatible so that dynamic linker can't
choose any implementation?


> I wonder if Qgis can load the python library in the same way it loads
> libqgispython, so that the python symbols are available to libqgispython
> when it's loaded?  Then it could load whichever python is "default",
> whatever that may mean, or have a Qgis preference (like setting the GRASS
> location) to let the user choose a Python to use.

Do you think that this will work? Let QGIS dynamically load python
library, and if loaded successfully, load also libqgispython? It makes
some sense to me but isn't this something that dynamic linker is
better suited to do?


> Otherwise, whatever is done to make all the PyQt and Qgis python extensions
> "proper" won't matter, since libqgispython will be stuck with whichever
> python it was compiled with.

So does this mean that both libqgispython and sip/pyqt/pyqgis share
the same problem that they link to a specific python?

Btw. is there any good reading on web about these OSX-specific linking
issues in general to get a bigger image?

Martin
_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user

[William Kyngesburye]

On Nov 14, 2008, at 6:30 PM, Martin Dobias wrote:

> libqgispython expects that dynamic linker loads the python library.
> But I don't understand why we need to avoid it. Are python
> implementations on OS X incompatible so that dynamic linker can't
> choose any implementation?
>
There's dynamic linking and static linking for shared libraries.  
Generally, OSX expects static linking for libraries, and dynamic  
linking for plugins/modules.

Whenever you link with the compiler with -lfoo or -framework foo, it  
will be statically linked with a specific path (unlike Linux where I  
believe just the library name is stored in the binary and  
LD_LIBRARY_PATH and ld.conf set a search path).

> Do you think that this will work? Let QGIS dynamically load python
> library, and if loaded successfully, load also libqgispython? It makes
> some sense to me but isn't this something that dynamic linker is
> better suited to do?
>
So, yes, I'm suggesting dynamically linking Python instead of the  
normal static linking.  OSX does have a DYLD_LIBRARY_PATH, but I'm not  
sure how that applies to frameworks, and it's not easily configured by  
the user for applications.  Oh, I see DYLD_FRAMEWORK_PATH also (from  
dyld), but it doesn't appear that dlopen uses that.

You could try the known paths for the Python framework, and also make  
it configurable by the user as a Qgis preference.  Then dlopen() that.


Hmmm...  A possibility: compile and link statically as Qgis does now,  
use install_name_tool to change the python link to drop the path (this  
is how the Qt frameworks are initially).  The linker at runtime then  
will use DYLD_FRAMEWORK_PATH and its internal default path to search  
for the python binary.  A pseudo-dynamic linking, no need to fuss with  
dlopen() and searching for python or a preference.  A user-installed  
python framework will override the system python, as expected.

>
>> Otherwise, whatever is done to make all the PyQt and Qgis python  
>> extensions
>> "proper" won't matter, since libqgispython will be stuck with  
>> whichever
>> python it was compiled with.
>
> So does this mean that both libqgispython and sip/pyqt/pyqgis share
> the same problem that they link to a specific python?
>

Yes.

> Btw. is there any good reading on web about these OSX-specific linking
> issues in general to get a bigger image?


Xcode documentation (it's all online at Apple).  GCC/LD man pages on  
an OSX Mac with Xcode have OSX-specific info also (they might also be  
on other systems).

A lot of the finer details is just my accumulation over the years ;)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect


_______________________________________________
Qgis-user mailing list
Qgis-user@...
http://lists.osgeo.org/mailman/listinfo/qgis-user