QGIS » QGIS Application

... dynamic_lookup seems to work. Maybe the load order is different. Maybe symbols are not looked up at load time, but at usage time.

I'd like to have a definite answer about other solutions before applying this fix.

William, you explain the solution clearly and concisely in the last paragraph of the bug report. The shared code needs to be moved to a library. I'm baffled why others are no longer willing to use cross-platform design patterns.

I solved this once for GRASS several years ago and until now, the design pattern remained in use. Relying upon special options or load order tends to reseult in the problem reappearing anytime something changes.

The basic issue is that on Linux, libraries and plugins are interchangeable and on the Mac they are not. In CMake terms, MODULE and SHARED produce the same type of output on Linux but produce different types of output on a Mac. Linux can used a MODULE as if it were a SHARED; a Mac cannot.

A Mac plugin is a leaf executable. It can only be loaded on demand and not linked as a library. A Mac library is a non-leaf executable. It is automatically loaded because an app, plugin or another library is linked to it and cannot be loaded on demand. Perhaps some or all of this is overridable by special options but that make the system less straightforward.

The cross-platform design pattern is that share code must always be in a library. If code originally written just for a plugin is found to be useful elsewhere, it should be moved either to a existing library or to a new library.

I'd like to add that QGIS 1.9.90-Alpha fails immediately when I enable the GRASS plugin from the plugin manager on OSX 10.6.8 on a MacBook Pro. This is the same behavior exhibited by Wroclaw (don't have version number available).

This problem does cause a crash everytime.

That --no-undefined flag is causing trouble. The OS X ld does not have that option (OSX ld is a custom job), but it does have "-undefined error" (or "-undefined warning", and others, similar to my temporary fix for the provider). Note that the default is error.

Strangely, it only appears in module linking (so far). CMAKE_SHARED_LINKER_FLAGS doesn't seem to do anything - I don't see the flag in any library linking. Haven't got as far as the QGIS app to see if it appears from CMAKE_EXE_LINKER_FLAGS.

William Kyngesburye wrote:

That --no-undefined flag is causing trouble. The OS X ld does not have that option (OSX ld is a custom job), but it does have "-undefined error" (or "-undefined warning", and others, similar to my temporary fix for the provider). Note that the default is error.

Well, that's just to produce warnings - if it doesn't work on OSX just disable it:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f7bf497..9449b66 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -399,11 +399,11 @@ IF (WIN32)
   SET(DLLIMPORT "__declspec(dllimport)")
   SET(DLLEXPORT "__declspec(dllexport)")
 ELSE (WIN32)
-  IF(PEDANTIC)
+  IF(PEDANTIC AND NOT APPLE)
     SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--no-undefined")
     SET(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,--no-undefined")
     SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--no-undefined")
-  ENDIF(PEDANTIC)
+  ENDIF(PEDANTIC AND NOT APPLE)

   SET(DLLIMPORT "")
   SET(DLLEXPORT "")

But that might also be an issue for different versions of gcc on Linux - waiting for the nightly builds to see - so I didn't apply that yet.

Jürgen Fischer wrote:

But that might also be an issue for different versions of gcc on Linux - waiting for the nightly builds to see - so I didn't apply that yet.

Apparently not a problem on Linux - applied in d2fbcfeb

is this fixed now?

Seems to work, with some simple testing.