stellarium 0.10.5

[macsforever2000@…]

Please update stellarium to version 0.10.5.

[macsforever2000@…]

A simple version bump did not work for me.

[raimue@…]

Yes, I noticed. But I have not investigated yet why the new version fails.

[michaelld@…]

Cc Me!

[michaelld@…]

Two items on the upgrade:

(1) watching 'configure' do it's thing: zlib and iconv end up being those provided by OSX, and should instead be those provided by MacPorts.

(2) At least for me (MacBook Pro early 2009, 10.5.8 latest, XCode 3.1.3, MacPorts 1.9.0 using dports from SVN): I get the errors:

[ 70%] Building CXX object src/CMakeFiles/stellarium.dir/main.cpp.o
Linking CXX executable stellarium
ld warning: in /opt/local/libexec/qt4-mac/lib/QtOpenGL.framework/QtOpenGL, file is not of required architecture
ld warning: in /opt/local/libexec/qt4-mac/lib/QtScript.framework/QtScript, file is not of required architecture
ld warning: in /opt/local/libexec/qt4-mac/lib/QtGui.framework/QtGui, file is not of required architecture
ld warning: in /opt/local/libexec/qt4-mac/lib/QtSql.framework/QtSql, file is not of required architecture
ld warning: in /opt/local/libexec/qt4-mac/lib/QtNetwork.framework/QtNetwork, file is not of required architecture
ld warning: in /opt/local/libexec/qt4-mac/lib/QtCore.framework/QtCore, file is not of required architecture
ld warning: in /opt/local/lib/libintl.dylib, file is not of required architecture
ld warning: in /opt/local/lib/libintl.dylib, file is not of required architecture
ld: in /opt/local/lib/libxml2.2.dylib, file is not of required architecture for architecture ppc
collect2: ld returned 1 exit status
Undefined symbols for architecture i386:
  "QGLContext::deleteTexture(unsigned long)", referenced from:
      StelTexture::~StelTexture()in StelTexture.cpp.o
      StelTexture::~StelTexture()in StelTexture.cpp.o
  "QGLFramebufferObject::QGLFramebufferObject(QSize const&,
          QGLFramebufferObject::Attachment, unsigned long, unsigned long)", referenced from:
      StelAppGraphicsWidget::initBuffers()       in StelAppGraphicsWidget.cpp.o
      StelAppGraphicsWidget::initBuffers()       in StelAppGraphicsWidget.cpp.o
  "QGLContext::bindTexture(QImage const&, unsigned long, long,
          QFlags<QGLContext::BindOption>)", referenced from:
      StelTexture::glLoad()      in StelTexture.cpp.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cc9DTlnj.out (No such file or directory)

so, something is going wrong with the architecture detection, in patching (by the Portfile) or elsewhere. I'm looking into it, since I have time today & I enjoy using Stellarium. No promises.

[michaelld@…]

Looks like:

(1) "cmake" is also finding the OSX-installed opensll instead of that of MacPorts -- outputs for this and the above in (1) follow; I'm trying to figure out the correct arguments to 'cmake' to get it to use the correct version:

-- Found OpenSSL: /usr/lib/libssl.dylib;/usr/lib/libcrypto.dylib
-- Found ZLIB: /usr/lib/libz.dylib
-- Found Iconv: /usr/lib/libiconv.dylib

(2) "cmake" is setting "CMAKE_OSX_ARCHITECTURES:STRING=" (i.e., to nothing), instead of to a specific architecture. This might be causing it to try to compile for PPC instead of i386 (in my case, since I'm using 10.5.8).

Still investigating.

[michaelld@…]

The file "CMakeLists.txt" changed between releases, and that messed up the Portfile reinplace. I've figured out how to augment the Portfile for this change, as well as to use the MacPorts-provided opensll, zlib, and iconv. Even with those, I'm still getting the same "undefined symbols" as before.

[michaelld@…]

I'm still working on this issue, but I think (right now) it has to do with the way Qt4-Mac is installed. I'm attaching a Portfile diff if anyone else wants to help debug (from 0.10.4 to 0.10.5, with all the changes listed above).

[michaelld@…]

Diffs to upgrade stellarium Portfile from 0.10.4 to 0.10.5; still won't compile, but getting closer.

[michaelld@…]

Still trying, as time allows. I -think- the issue is that qt4-mac was compiled such that, if you look at qt4-mac/include/QtOpenGL/qgl.h:87, the 'compat' features are not used ... but, for some reason stellarium -is- trying to use them, which creates conflicting method signatures between the library (uses 'int') and stellarium (uses 'long').

[michaelld@…]

I think I know the issue now. qt4-mac is (I'm betting) compiled with the 10.5 SDK; stellarium is trying to use the 10.4 SDK. 10.4 defines "GLuint" as "long" while 10.5 defines it as "int", which are not library compatible. So, I'm now searching for how to specify the SDK to use for cmake.

[michaelld@…]

More notes:

• Upgrading the SDK to 10.5 does indeed result in the port successfully compiling and installing, but the resulting executable does not work properly. Trying to execute it results in a dialog box that says "You can't open the application 'Stellarium.app' because it is not supported on this architecture. Showing the contents and starting the MacOS executable results in Stellarium running correctly, just the UI being very slow (responses being on the order of seconds, not "almost instantaneously" as the normal .app does).

• The current Portfile (for 0.10.4) also doesn't work with the current qt4-mac (4.6.2_2); it produces the same linker issues as my augmented port (via the attached diff) -- so, it, too has issues with the chosen SDK (10.4).

Given the above, I believe the problem is actually an interface issue between Qt4 and OSX (including OpenGL), not Stellarium per se. I'm updating the attached Portfile diff to my latest version, which does compile fully on 10.5 i386, but otherwise I don't know what else to do to make this port work; clearly, the downloadable .app does work, so there is a way to make it do so.

[michaelld@…]

Patch to upgrade Stellarium portfile such that 0.10.4 compiles cleanly, but does not execute.

[michaelld@…]

Patch to upgrade Stellarium portfile such that 0.10.5 compiles cleanly, but does not execute.

[michaelld@…]

< ​http://stellarium.org/wiki/index.php/Compilation_on_Macosx > implies that we're supposed to use the 10.4u SDK. Maybe that really makes a difference?

[michaelld@…]

< ​http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x > states that 4.6.3 for Cocoa is meant for 10.5 or 10.6 only, so no 10.4 support any longer -- 10.4 support for the Carbon version only now. I wonder if the Stellarium folks know about this change, and if it means any code changes for them (beyond changing the few 10.4 oriented variables for CMake)?

[michaelld@…]

Reading the stellarium.org wiki link again, they certainly do know. Still no idea why this doesn't "just work" ...

[michaelld@…]

Another data point: I can confirm that if I (1) download Qt mac cocoa 4.6.3 precompiled & install that (goes into /Developer/ and /usr ); (2) edit the CMakeLists.txt for stellarium to use 10.5 (10.4u does not work correctly; I've tried it); (3) do 'cmake', 'make', 'make install' as usual; then (4) edit the created Stellarium.app's contents to be inline with MacOS X expectations ... then the resulting .app does work correctly, but only when executed from within (via runnning 'Contents/MacOS/stellarium'). The .app itself still claims not the correct architecture.

[michaelld@…]

Following up on the previous post: If I recreate what the Portfile does by hand, and just include or not the "-DQT_QMAKE_EXECUTABLE" part, then I find that the version that does include it (which uses the MacPorts' installed Qt) behaves exactly as I've documented above and just isn't functional; the one which doesn't include it (uses the one I installed from download), works as described above. I'm trying upgrading qt4-mac to 4.6.3 to see if that's the issue.

[michaelld@…]

Upgrading to Qt4-Mac 4.6.3 at least allows the internal executable to function. I'm investigating how to get the external .app to register the architecture correctly now.

[michaelld@…]

Fixed in [68848].