Stellarium crash on start

Bug #1005155 reported by Alexander Wolf on 2012-05-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I downloaded the .dmg (sourceforge), opened it and copied Stellarium to my Applications folder. Stellarium crashes immediately when I try to start it. Seems to be some problem with QTOpenGL, but I have no idea what to do about it.



Process: stellarium [8909]
Path: /Applications/
Identifier: org.stellarium.Stellarium
Version: ??? (0.11.3)
Code Type: X86-64 (Native)
Parent Process: launchd [208]

Date/Time: 2012-05-27 07:22:59.334 -0400
OS Version: Mac OS X 10.7.4 (11E53)
Report Version: 9

Crashed Thread: 0

Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: QtOpenGL.framework/Versions/4/QtOpenGL
  Referenced from: /Applications/
  Reason: image not found

Binary Images:
       0x10d2a5000 - 0x10d90ffef +org.stellarium.Stellarium (??? - 0.11.3) <653046FD-BDB1-33BA-A940-2B8850418E80> /Applications/
    0x7fff6cea5000 - 0x7fff6ced9baf dyld (195.6 - ???) <0CD1B35B-A28F-32DA-B72E-452EAD609613> /usr/lib/dyld
    0x7fff8c1e7000 - 0x7fff8c1f7ff7 (1.7.7 - 1.7.7) <0CA11278-746C-353A-923B-BCC0047190C3> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff8fecf000 - 0x7fff8fecffff (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa

Changed in stellarium:
importance: Undecided → High
assignee: nobody → treaves (treaves)
tags: added: mac-os-x
Changed in stellarium:
status: New → Confirmed
importance: High → Critical
treaves (treaves) wrote :

Th issue is getting the Frameworks modifed to be embedded; this broke with OS X 10.7. I have started to work on it, but it's a real pain.

RalphBln (schaef) wrote :

I don't know if this is of much help, but I managed to compile an intel-only .dmg of stellarium 11.3 (on an intel MBP, running 64-bit Mac OS 10.7.4).

Compiling and installing went smoothly. I ran into problems during make macosx_bundle.

One of the problems is that only checks for fat, ppc, and i386 when examining the embedded dynlibs. On 64-bit machines, /usr/bin/file shows "Mach-O 64-bit dynamically linked shared library x86_64". So should also look for "x86_64", otherwise, you get "what to do about $absname being $arch" messages (with $arch being empty) for every embedded library, and nothing is copied.

I just added the following lines to the architecture sub routine:

    elsif ( grep(m/x86_64/, @output) ) {
 $retval = $current_arch;

This helped. Libraries got copied to the Frameworks directory, and install_name_tool changed the install names correctly.

(It's better to return $current_arch here, since uname returns i386 under Lion 64-bit, and the folders for the different architectures are created based on the output of uname).

Don't know about ppc though...

Alexander Wolf (alexwolf) wrote :

Thanks for suggestion, I'm add patch but I can't try it.

RalphBln (schaef) wrote :

Another thing: The Qt plugins should be copied to the plugins directory (as stated in qt.conf) instead of the MacOS dir.


Change line 22:
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines} ${CMAKE_INSTALL_PREFIX}/MacOS

mkdir ${CMAKE_INSTALL_PREFIX}/plugins
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines} ${CMAKE_INSTALL_PREFIX}/plugins

Otherwise Qt finds and uses the plugins in /Developer/Applications/Qt/plugins on machines where Qt is installed. The plugins there in turn include links back to the Qt frameworks in /Library/Frameworks which leads to the Qt frameworks being loaded twice resulting in "Class XYZ is implemented in both .../stellarium-0.11.3/builds/macosx/ and /Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined." messages an stellarium crashing.

Alexander Wolf (alexwolf) wrote :

Thanks for suggestion again! Please check a new revision.

RalphBln (schaef) wrote :

Oh, I forgot: The next line (23, now 24) must also be changed

for f in ${CMAKE_INSTALL_PREFIX}/MacOS/{imageformats,iconengines}/*.dylib; do

for f in ${CMAKE_INSTALL_PREFIX}/plugins/{imageformats,iconengines}/*.dylib; do

Alexander Wolf (alexwolf) wrote :

Fixed, please check it.

RalphBln (schaef) wrote :

Ah, sorry, I should have tested before posting.

The plugins should not reside in subfolders of the plugins dir. My mistake.

So lines 22-24 in should be:

mkdir ${CMAKE_INSTALL_PREFIX}/plugins
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines}/* ${CMAKE_INSTALL_PREFIX}/plugins
for f in ${CMAKE_INSTALL_PREFIX}/plugins/*.dylib; do

This is tested in working on my machine with Qt frameworks installed.

Apologies for the confusion.

Alexander Wolf (alexwolf) wrote :

Fixed too, please check it again.

RalphBln (schaef) wrote :

Okay, checked. The plugin depencies are okay.

However, copying of framworks and libraries still fails, because under Lion /usr/bin/arch can give inaccurate information (i386 instead of x86_64), leading to the creation of a "i386" directory and the subsequent attempt to copy to a (non-existing) "x86_64" directory.

This is why I recommended returning $current_arch rather than "x86_64" from the architecture sub routine in I agree, however, that this is a rather dirty fix.

A maybe better fix would be to use "uname -m" instead of "arch" for detecting the current architecture (this seems to return the correct architecture on Lion systems):

Change, line 16 from:

my $current_arch = `/usr/bin/arch`;


my $current_arch = `/usr/bin/uname -m`;

Alexander Wolf (alexwolf) wrote :

Hmm... can you write patch for fully building working package?

RalphBln (schaef) wrote :

Here's the patch with my changes since rev 5457. If you need a patch with all changes mentioned in the last comments, pls. let me know (I have to go now, so I won't be able to do this right now).

Alexander Wolf (alexwolf) wrote :

Yes, I need a full patch

RalphBln (schaef) wrote :

Okay, here's the complete patch.

Alexander Wolf (alexwolf) wrote :

I'm add your patch, thanks! Can you check it now?

Changed in stellarium:
status: Confirmed → In Progress
assignee: treaves (treaves) → RalphBln (schaef)
milestone: none → 0.11.4
RalphBln (schaef) wrote :

Checked. Works perfectly.

Alexander Wolf (alexwolf) wrote :

We upload new version of Stellarium - please check it.


Changed in stellarium:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers